Subject: [secdir] Resend: Secdir review of draft-altman-tls-channel-bindings-10

From: Magnus Nyström <[email-masked]>
Date: Tue, 4 May 2010 22:42:59 -0700

Resend since I used the wrong email address for tools.ietf.org.

---------- Forwarded message ----------
From: Magnus Nyström <[email-masked]>
Date: Tue, May 4, 2010 at 10:23 PM
Subject: Secdir review of draft-altmann-tls-channel-bindings-10
To: [email-masked], [email-masked],
[email-masked]

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This document defines channel binding types for Transport Layer Security
(TLS), in accordance with RFC 5056.

The review is a follow-up of the review I made back in October 2007. Since
then, the unfortunate situation with a delta between an early implementation
of the "tls-unique" channel binding and the description in the IANA
registration was discovered and this prompted several updates to the draft.

As far as I can tell, the current draft solves the issue by adopting the
early implementation. It also contains several prominent warnings to
implementers about the situation.

Two of my comments from my review of -07 still stands:

1. Section 2 should reference RFC 5056, not RFC 5246. This is a bug.
2. It would have been nice with an example of an authentication mechanism
using one of the channel bindings in this document, perhaps in the form of
an illustrative appendix.

-- Magnus

-- 
-- Magnus

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 5 May 2010 01:00:10 -0500

> like any other last call comments.

Thanks.

> 1. Section 2 should reference RFC 5056, not RFC 5246. This is a bug.

Noted many, many times :)  There's a note to the RFC-Editor; it will get
fixed!

> an illustrative appendix.

Now that SCRAM is on the RFC-Editor queue I suppose we could lift the
examples from there and add TLS message descriptions to make a complete
example, but I don't really care to provide actual keys, randoms, key
derivations, ... -- ENOTENOUGHTIME.  We could also do the same with
Kerberos, but the examples would be even more opaque.  I might draft
something, but if it'd require another last call then I'd rather file an
I-D, seeking publication as Informational, to provide the examples.

Thanks,

Nico
--