On Wed, Mar 7, 2018 at 4:39 PM, Sean Turner <s...@sn3rd.com> wrote: > > > > 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. >
Indeed, I am aware of at least one. -Ekr > > >> 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
