Subject: [Ietf-krb-wg] PROTO review of draft-josefsson-kerberos5-starttls-03.txt

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 05 Dec 2008 03:09:01 -0500

The following are issues I found in doing a review of starttls-03.

Item 4 is a serious technical issue which must be addressed in some
fashion.  This issue and a related one are already under discussion
in another thread.

Items 8, 9, and 10 are procedural issues which must be corrected
before this document can be sent to the IESG; however, this does not
need to happen before the start of the WGLC (but see below).

The remaining issues are all relatively minor comments which I offer
as an individual reviewer.  Like comments from any other participant,
these must be addressed before the document can leave the WG.  This
does not need to happen before the start of the WGLC; these comments
can be addressed along with comments received during WGLC.

Note that we cannot run a WGLC on an expired draft, so a new version
will be required in any event before we can start a WGLC.  I suggest
that Simon resolve any issues he feels can be resolved quickly before
submitting a new document, and leave the rest for the next revision.

-- Jeff

[JTH.1] (General) This document uses numbered references rather than
        using mnemonic identifiers.  While this is acceptable, IMHO
        it makes the document harder to read, as I can tell immediately
        what a reference like [RFC4120] means, but a reference like [3]
        can only be interpreted by interrupting the flow of reading to
        check the list.  In addition, in a document which contains
        ASN.1 context tags, it can be confusing to use the same syntax
        both for ASN.1 context tags and for references.

[JTH.2] (Section 2) This leaves the extension bit TBD, which is correct
        since IANA will decide what bit to assign.  However, if there
        is some reason to prefer a particular value, IANA considerations
        should mention this.

[JTH.3] (Section 2) As I understand it, once this extension is started,
        there is no going back.  If the TLS handshake fails, then the
        conversation is over and no further messages can be exchanged
        on the same TCP connection.  Is this the case?  If so, I think
        this could be made more clear (in the paragraph which begins
        "If for any reason the handshake fails..."); if not, then there
        needs to be some description of how to resynchronize after the
        TLS handshake failure (is this even possible?)

[JTH.4] (Section 3) The use of channel bindings here is underspecified
        and potentially dangerously insecure.  See my separate message
        on this issue.

[JTH.5] (Section 5) Are there IANA considerations related to the use
        of "tls" as a Proto value in a SRV record name?  Note that
        the terminology used in describing the name and RDATA of a
        SRV RR is defined by RFC2782, not RFC4120.

[JTH.6] (Section 7) I suggest that both occurances of "it is suggested"
        appearing in this section be reworded to use SHOULD; I believe
        there are sufficient security and interoperability reasons,
        respectively, for doing so.

[JTH.7] (Section 8.1) The reference to RFC 4346 is out of date, and
        perhaps should be updated.

[JTH.8] Naturally, all of the boilerplate on this document is out of
        date and will need to be updated.

[JTH.9] Change Intended Status to Informational

[JTH.10] Add "Updates: 4120 (if approved)" header, and add "This
         document updates RFC 4120" to the abstract, as described
         in ID-Checklist 3.1.D

[JTH.11] The security considerations are a bit sparse.  While much
         is covered by references to Kerberos, TLS, and the Kerberos
         TCP extension framework, some things should be called out
         explicitly.  For example, this extension does not provide
         protection against a MITM attack unless the client correctly
         validates the KDC's certificate.

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

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 05 Dec 2008 13:10:25 +0100

> The following are issues I found in doing a review of starttls-03.

Thank you for review!

> submitting a new document, and leave the rest for the next revision.

Good idea.

>         both for ASN.1 context tags and for references.

Done.

>         is some reason to prefer a particular value, IANA considerations

There is no reason to prefer any particular bit as far as I can see.

>         on the same TCP connection.  Is this the case?  If so, I think

Yes.

>         TLS handshake failure

Good observation, should be fixed now.  I have also added another
paragraph to cover shutdown of the TLS/TCP connection on successful TLS
handshake.

> (is this even possible?)

In theory, yes it can be made to work with TLS.  However, many
implementations have problem in this area, and more importantly, I don't
see any benefit in allowing the TCP connection to be re-used for
anything else.

>         and potentially dangerously insecure.  See my separate message

I don't see exactly how to fix this right now, so I'm leaving the text
as is until we approach consensus on a solution here.
>         of "tls" as a Proto value in a SRV record name?

Not that I'm aware of.  Looking at the IANA sections of RFC 2782 and RFC
4120 I don't see anything related to DNS SRV.

> Note that the terminology used in describing the name and RDATA of a

Good point.  Given that both documents are already referenced early in
that paragraph, I removed 'Using the terminology of Section 7.2.3 of RFC
4120, '.

>         respectively, for doing so.

Done.

>         perhaps should be updated.

Done.

>         date and will need to be updated.

This can be done later on, since the IETF still permits the old
boilerplate.  It has been suggested that the boilerplate text will
change.  Finally, there is no stable release of xml2rfc that supports
the new boilerplate.  See:

http://thread.gmane.org/gmane.text.xml.rfc/1995

> [JTH.9] Change Intended Status to Informational

Done.

>          document updates RFC 4120" to the abstract, as described

Done.

>          validates the KDC's certificate.

Done.

Expect an updated draft shortly.

/Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 05 Dec 2008 11:18:18 -0500

> the new boilerplate.  See:

It doesn't have to be updated (yet) to reflect RFC4748, but the copyright 
dates will need to change.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 05 Dec 2008 11:27:49 -0500

>>          document updates RFC 4120" to the abstract, as described

Only partly.  You updated the abstract, but the header still doesn't show 
"Updates: 4120 (if approved)".  You should fix that whenever you send in 
the next version.

Aside from that, and JTH.4, I believe all the issues I raised are resolved. 
It may still be necessary in the future to update the boilerplate to 
reflect RFC 4748, depending on when we finish, but I'm not considering that 
an open issue.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 05 Dec 2008 18:41:33 +0100

> "Updates: 4120 (if approved)".  You should fix that whenever you send in 

Ah, fixed in my local copy available from:
http://josefsson.org/krb5starttls/

> reflect RFC 4748, depending on when we finish, but I'm not considering that 

Right.  I'll follow up your JTH.4 aka channel-binding comments in
separate posts.

/Simon