Subject: Re: KDC StartTLS vs. FAST Armor analysis

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 9 May 2007 21:43:48 -0400 (EDT)

On Thu, 26 Apr 2007, Nicolas Williams wrote:

> On Thu, Apr 26, 2007 at 08:30:21AM -0400, Sam Hartman wrote:
> > So, how do we make forwmard progress on this issue?
>
> First I'd like to know what room there is for having both.  Personally I
> think only one should be required (but required by what spec?).

That's up to the working group.  We agreed in Prague that we want to do at
least one.  We could do both, and one option would be to do one as
standards track and one as informational.

I would like to see a quick resolution to this question.  To that end, I'm
asking for comments on whether people would like to see us work on FAST
armor, starttls, or both.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Fri, 11 May 2007 09:51:12 -0400

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> I thus favor 'both' since it is not even clear that these
    Simon> technologies are mutually exclusive.  If there is overlap
    Simon> in some area(s), we need to know which areas, and also
    Simon> which areas the WG is actually interested in.

<hat role="individual">

I think Nico's comments give us an understanding of where there is
overlap.  I don't favor a problem statement.  I do favor working on
both: fast as a standards track RFC and starttls as an experimental
RFC with the understanding that if fast proves difficult to deploy we
promote starttls.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 11 May 2007 11:12:31 -0400

>>  <hat role="individual">
    >> 
    >> I think Nico's comments give us an understanding of where there
    >> is overlap.  I don't favor a problem statement.  I do favor
    >> working on both: fast as a standards track RFC and starttls as
    >> an experimental RFC with the understanding that if fast proves
    >> difficult to deploy we promote starttls.

    Simon> The choice of document to select for standards track seems
    Simon> arbitrary to me.  What made you prefer that approach?

Well, honestly for me, I could fall back on favoring the proposal I
authored and it wouldn't be particularly unreasonable.

The actual reason are more complicated.  As far as I can tell starttls
and fast do exactly the same things.  Fast does not depend on another
security framework and works better with UDP.  Fast already has the
channel bindings issues covered; starttls would require work in this
regard.

Also, as an implementer I know I can implement fast.  I am not sure
there is a TLS implementation that meets my license constraints.  So,
if the WG chooses TLS, it may be difficult or impossible for MIT
Kerberos to support the standards track solution.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 May 2007 10:16:38 -0500

On Thu, May 10, 2007 at 02:32:31PM +0200, Simon Josefsson wrote:
> If the WG is to make a choice here, I believe it needs to establish a
> problem statement.  That will lead to an informed decision.

Alternatively we might agree that the two have the same fundamental
properties.

> To me, your question is like asking which is better of C and Java
> without knowing the problem you want to solve.

If all you want is a Turing complete language...  :)  But yes, point
taken.

> I thus favor 'both' since it is not even clear that these technologies
> are mutually exclusive.  If there is overlap in some area(s), we need to
> know which areas, and also which areas the WG is actually interested in.

I do not disfavor 'both'.  I prefer only one be REQUIRED.  I trend
towards preferring Larry's proposal as the REQUIRED one.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 May 2007 10:25:46 -0500

> channel bindings issues covered; starttls would require work in this

Those are the reasons that make me trend to prefer FAST Armor.

> Kerberos to support the standards track solution.

We don't have that problem, but as long as we share a code base with MIT
then avoiding unnecessarily causing MIT license problems is probably in
our interest.  So this too counts for me.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 May 2007 14:32:31 +0200

yxa.extundo.com
X-Virus-Status: Clean
Sender: [email-masked]
Precedence: bulk

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 11 May 2007 17:01:28 +0200

> RFC with the understanding that if fast proves difficult to deploy we

The choice of document to select for standards track seems arbitrary to
me.  What made you prefer that approach?

I can understand the preference to avoid the work involved with
producing a problem statement.  (I'm rather confused exactly what
problems people perceive that either of these proposal actually solve,
and doesn't solve, so personally I'd find a problem statement helpful.)

However, if we don't do a problem statement, then I believe it is
important to make it clear that the WG chose one document not based on
objective and written-down technical reasons.

I thought Nico's evaluation is a good starting point for a problem
statement and document comparison analysis.  It needs to be updated
until there is consensus on it, though.  There were several flaws in the
initial writeup, which is normal for a -00 (or even pre -00) attempt.
More importantly, it is not clear which of the metrics used in the
evaluation are important to the WG.  Some may not be important at all,
and there may be others that are important.

/Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 16 May 2007 18:19:20 -0400

> RFC with the understanding that if fast proves difficult to deploy we

OK; I think I'm ready to suggest a course of action here.
First, I want to be clear -- Nico's assignment was to analyze and compare 
the FAST armor and STARTTLS proposals, and report back to the list on what 
he found.  I believe he has fulfilled that assignment well, and thank him 
for his efforts in this area.

Please bear in mind that this is Nico's report on what Nico found, and it 
does not require the consensus of the group.  Authors and proponents of 
both proposals have had a chance to comment on Nico's findings, in public 
where their words can be considered by the working group.

What I'm hearing at this point is that there are some people who support 
working on both FAST armor and STARTTLS, and no one who objects to doing 
so.  There also seems to be agreement that at least one of these should be 
published on the standards track, but given the small number of people 
participating in discussion, I see nothing resembling consensus on which.

So, I'm going to propose including both items in the charter, but leaving 
their intended status unspecified.  This would be consistent with the 
remainder of the charter, which does not specify intended status for any 
work items.

Comments?

-- Jeff