Subject: Re: [Ietf-krb-wg] CONSENSUS CALL: STARTTLS to informational

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 04 Dec 2008 11:54:01 -0500

--On Thursday, November 20, 2008 03:49:24 PM -0600 Jeffrey Hutzelman 
<[email-masked]> wrote:

> Since the meeting, I have seen a number of comments on Jabber and on this
> mailing list to the effect that we should publish STARTTLS immediately as
> an informational document.  Some of those comments also suggested that we
> should publish FAST as informational when it is ready, and upgrade one or
> both documents when necessary/appropriate.
>
> I believe there is a reasonably strong consensus to publish STARTTLS as
> an  informational document, and I would like to verify that such a
> consensus  actually exists.  To that end, I am beginning a consensus call
> on the  question of the intended status of STARTTLS.  This call will run
> until  23:59 EST on Monday, Dec 1, 2008, which is slightly over a week
> from now.  Please respond by then, or let me know if there is some reason
> you need  more time.

I've reviewed the comments sent in response to this call, as well as 
comments on the mailing list and in jabber which led up to it.  Where the 
same person made multiple comments, I assume that a more recent comment in 
response to this consensus call takes precedence over an earlier comment 
made before the call was issued.  In any case, I don't think this makes a 
notable difference.

I found that Love, Nico, Jeff Altman, and Leif all favored publishing both 
STARTTLS and FAST as informational documents, then promoting something to 
standards track later if/when it becomes necessary.

Simon Josefsson and Henry Hotz both expressed a desire to publish STARTTLS. 
Simon said he would prefer standards track but would accept informational. 
Henry said he had no preference.

Based on those comments, I'm finding that there is consensus to publish 
STARTTLS as an Informational RFC, and I will start a last call shortly.

Several people also suggested publishing FAST as informational.  I don't 
believe I have enough information to judge consensus on that question, as 
it wasn't included in the consensus call and so there may be some people 
who have thoughts on the matter but have not had an opportunity to comment. 
So, I'm leaving that question unresolved for the moment.

However, I will point out that there are a couple of potential issues. 
First is that FAST and the preauth framework are defined in the same 
document.  If we want to publish the former as informational but the latter 
on the standards track, we would have to separate them into two documents, 
and I don't know how difficult that is, or even if it's possible at all. 
Second, we have other documents such as the OTP draft which have real 
normative dependencies not just on the preauth framework but on FAST.  It 
may be possible to publish FAST as informational and OTP on the standards 
track, but it would look awfully strange IMHO.

-- Jeff
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 Dec 2008 13:08:18 -0600

> standards track later if/when it becomes necessary.

Do not forget my request for channel binding between pre-auth and

> track, but it would look awfully strange IMHO.

All true, but there's no reason that OTP couldn't be made to work over
STARTTLS as well.

This is the architectural problem with having two solutions: how does
pre-auth interact with the secure channel established by either
solution?

FAST doesn't necessarily do channel binding in the traditional way, but
it should bind pre-auth where feasible or protect it otherwise (e.g.,
OTP).

STARTTLS, IIRC, doesn't provide any channel binding.

Not providing channel binding is OK, of course, in that without it the
client must be able to authorize the KDC given the KDC's certificate
before sending the KDC any pre-auth that's not bound to the channel.

If in the end one solution provides channel binding and the other does
not, then I will support the one that does for the Standards-Track.

Nico
--