Subject: [Ietf-krb-wg] starttls as info

From: Sam Hartman <[email-masked]>
Date: Fri, 04 Apr 2008 14:09:33 -0400

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

    Simon> I don't understand the rationale behind publishing it as
    Simon> informational/experimental.  It seems it could be proposed
    Simon> standard from the start.  I would prefer this way forward.
    Simon> Since informational status has been suggested a few times,
    Simon> I'd like to understand what the reasons for preferring that
    Simon> approach could be.

    Simon> /Simon

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

Often, when the IETF has two technologies to accomplish the same task
it publishes one as informational and one as standards track.  I'd
rather see FAST as a standards track RFC than starttls.  I think their
functionality overlaps enough that it may not be a great idea to
publish both on the standards track.

However when you consider mandatory to implement for 5.3 the problem
becomes a bit more complicated.  Whatever is mandatory to implement
for 5.3 needs to be standards track.  We've also seen a number of
cases throughout the IETF where publishing something on the standards
track that ultimately ended up not being the mandatory to implement
option confused implementations.

So, if we are going to have a mandatory to implement solution for
protecting the exchange in 5.3, then we should not publish any of the
contenders for that on the standards track until we've chosen which
one will be the mandatory to implement.

I strongly believe that 5.3 should have a mandatory to implement
solution for protecting the exchange.

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

---

From: Larry Zhu <[email-masked]>
Date: Wed, 9 Apr 2008 15:42:49 -0700

Speaking as an individual, the start-tls approach is a one-off solution and it should not be promoted. I have the following architectural concerns:

1) it does not have a way to leverage Kerberos referrals. The client using start-tls need to directly trust the KDC certificate from the account realm, instead of using Kerberos cross realm TGT.
2) it is not clear how it can work with IAKERB.
3) the channel binding is underspecified, and it brings in AP_REQ currently, which mean it needs related texts copied/morphed from the kerb-fast draft.

This ID should have the "experimental" status.

--larry
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Friday, April 04, 2008 11:10 AM
To: Simon Josefsson
Cc: [email-masked]; Jeffrey Hutzelman
Subject: [Ietf-krb-wg] starttls as info

    Simon> /Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Apr 2008 17:53:02 -0500

On Wed, Apr 09, 2008 at 03:42:49PM -0700, Larry Zhu wrote:
> Speaking as an individual, the start-tls approach is a one-off
> solution and it should not be promoted. I have the following
> architectural concerns:

Excellent points, BTW.

> 1) it does not have a way to leverage Kerberos referrals. The client
> using start-tls need to directly trust the KDC certificate from the
> account realm, instead of using Kerberos cross realm TGT.

This could be fixed though.  I'm not sure if it could be fixed in ways
that can be easily implemented with a variety of off-the-shelf TLS
implementations though -- maybe someone can comment on this.

> 2) it is not clear how it can work with IAKERB.

(2) could be addressed by using DTLS instead of TLS.

> 3) the channel binding is underspecified, and it brings in AP_REQ currently, which mean it needs related texts copied/morphed from the kerb-fast draft.

The channel binding can be fully specified though.

> This ID should have the "experimental" status.

If these issues are not addressed, particularly (3), then I strongly
agree that starttls must not be on the Standards track.  It could be
informational if its limitations are clearly documented in the document.

Nico
--