> On Mar 7, 2018, at 16:35, Ben Campbell <b...@nostrum.com> wrote: > > > >> On Mar 7, 2018, at 2:49 PM, Sean Turner <s...@sn3rd.com> wrote: >> >> >> >>> On Mar 6, 2018, at 12:27, Ben Campbell <b...@nostrum.com> wrote: >>> >>> Ben Campbell has entered the following ballot position for >>> draft-ietf-tls-tls13-26: Yes >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> There has clearly been a lot of work put into this. It's a surprisingly >>> understandable document, given its length and the complexity of the >>> subject. I >>> am balloting yes, but I have a few minor comments and nits. None of these >>> are >>> showstoppers, so please do with them as you will. >>> >>> *** Substantive Comments: >>> >>> §4.1.2, first paragraph: " When a client first connects to a server, it is >>> REQUIRED to send the >>> ClientHello as its first message. " >>> >>> Is that intended to prohibit the use of STARTTLS or similar application >>> layer >>> patterns? (To be clear, this is not an objection, just a clarification >>> request.) >> >> No - this is just how it works TLS - clients send the ClientHello message >> first ;) > > I assume your response to mean that the point is merely that ClientHello is > the first message of the TLS handshake. As worded, I think some readers might > interpret this to mean that the client can send no other data at any layer > prior to ClientHello.
Well this is about TLS :) But, maybe r/its first message/its first TLS handshake message ? >>> §4.1.2, legacy_compression_methods: "Note that TLS 1.3 servers might receive >>> TLS 1.2 or prior >>> ClientHellos which contain other compression methods and MUST >>> follow the procedures for the appropriate prior version of TLS." >>> >>> Is that intended to require TLS 1.3 servers to always be willing and able to >>> negotiate 1.2? §4.2.1 has a similar assertion: >>> >>> "If this extension is not present, servers which are compliant with >>> this specification MUST negotiate TLS 1.2 or prior as specified in >>> [RFC5246], even if ClientHello.legacy_version is 0x0304 or later." >>> >>> But §4.2.3 says: >>> >>> "Note that TLS 1.2 defines this extension differently. TLS 1.3 >>> implementations willing to negotiate TLS 1.2 MUST behave in >>> accordance with the requirements of [RFC5246] when negotiating that >>> version." >>> >>> ... which seems inconsistent (noting that this paragraph talks about >>> "implementations" rather than "servers", so perhaps there's a subtle >>> difference? >> >> In short kinda, sorta yes: §s4.2.1 includes the following: >> >> Implementations of TLS 1.3 which choose to support prior versions of >> TLS SHOULD support TLS 1.2. > > That still says “which choose to support” Right so there might be some implementations that choose to not support prior versions. >> Not sure it’s inconsistent given that the 2nd quote is about the server >> needs to do with the information it’s getting from the client. > > I’m still confused. Is the server allowed to refuse to negotiate 1.2? Or is > the exception in §4.2.1 supposed to apply to all of the related MUSTs? Yes - TLS servers are allowed to refuse to negotiate earlier version; that’s deciding to not follow the SHOULD in §s4.2.1. If they negotiate an earlier version then do that version that’s what’s in §s4.1.2 and in §4.2.3. >>> §4.2.1.1: The section is marked for removal. Do you expect that RFC >>> implementations will ever need to interop with draft implementations? If so, >>> the information in this section may continue to be useful for some time. >> >> I think it’ll be useful for about as long as it takes for them to rev their >> code bases, which I am sure hoping is faster than the 6 or so weeks it’ll >> take for this draft to get to through the RFC editor’s queue. > > Okay. > >> >>> §D.5: This section has a lot of normative requirements that seem important. >>> I >>> wonder why it has been relegated to an appendix. >> >> §D.5 is about backward compatibility and though we negotiations with 1.2 is >> a SHOULD we say nada about earlier versions. And, we don’t want to say >> anything about earlier versions. And, some of this is technically repeated >> from other RFCs, eg. 5768 and 6176 saying don’t do SSL2/3. So, it ended up >> in an appendix. > > Okay. > >> >>> *** Editorial Comments and nits: >>> >>> §2: "If (EC)DHE key establishment >>> is in use, then the ServerHello contains a "key_share" extension with >>> the server’s ephemeral Diffie-Hellman share which MUST be in the same >>> group as one of the client’s shares. " >>> >>> missing comma prior to "which”. >> >> (grammar police are banging on my door as we speak) > > Well, my comment was labeled as editorial or nit :-) > >> So is the which clause restrictive or non restrictive? I’m going with this >> this clause being restrictive (hence no comma). > > I’ll let the grammar police at your door debate the merits of “which” vs > “that” for restrictive clauses :-) See the response to Adam’s comment :). But, yeah the RFC editor will definitely school me when the time comes. >>> §4.1.1: "Note that if the PSK can be used without (EC)DHE then non- >>> overlap in the "supported_groups" parameters need not be fatal, as it >>> is in the non-PSK case discussed in the previous paragraph." >>> >>> I read "need not be fatal" to mean that it may still be fatal at times. Is >>> that >>> the intent? >> >> Yes that is the intent. > > Okay. Would it be reasonable to offer guidance about when might want to treat > this as fatal even though it would have been possible to use the PSK without > (EC)DHE? So the fatal error is when the client and server are trying to negotiate (EC)DHE parameters and there’s no overlap in the supported_groups. This would occur in the “normal” case when the client is anonymous (i.e., client only sends ClientHello+key_share and no psk_key_exchange_modes/pre_shared_key) or when the client is using PSK+(EC)DHE for client authentication. But, that is described in the previous paragraph. Maybe another way to say it is: normally you’d throw an error if supported_groups didn’t overlap, but here since you’re not using them because you’re doing PSK-only you don’t. >>> §11: The IANA considerations have a number of constructions similar to >>> "SHALL >>> update/has updated". Is that text expected to collapse to "has updated" at >>> some >>> point? >> >> Yes - once we’ve gotten the a-okay from IANA, well as the RFC editor to make >> it just say “has updated” etc. > > Okay. > >> >>> §E.2.1: [BDFKPPRSZZ16] : Best citation anchor evar >> >> :) > > I am trying to decide if that should sound like a “Bill the Cat” utterance or > a sound effect for cartoon violence involving high voltage :-) > >> > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
