[TLS] Ben Campbell's No Objection on draft-ietf-tls-padding-03: (with COMMENT)
Ben Campbell has entered the following ballot position for draft-ietf-tls-padding-03: No Objection 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-padding/ -- COMMENT: -- -- Abstract: More in the abstract would be nice. Why'd would one want to do this? -- 1, first paragraph, last sentence: Can you elaborate on this? The motivation seems weak without a bit more. When would you choose to use this at all? Wouldn't it make more sense to fix the bug? -- 5, last sentence: Do you expect anyone to implement this MAY? It seems like this either needs to be stronger, or removed as a "why bother"? -- 6: I'm not sure I understand the meaning of "permanently assign the early code point for the padding extension in its ExtensionType registry". Does this mean that an early allocation was done for this? If so, it seems like the IANA section should still describe the code point being registered, or perhaps give a pointer to or description of the early allocation. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Ben Campbell's No Objection on draft-ietf-tls-cached-info-20: (with COMMENT)
Ben Campbell has entered the following ballot position for draft-ietf-tls-cached-info-20: No Objection 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-cached-info/ -- COMMENT: -- -section 4, paragraph 4: It might be helpful to have a little more guidance to clients for multi-tenant server environments. For example, the fact that it might want to cache different certs from the same server in the first place. Also, when might it be reasonable to violate the RECOMMENDED? - 4.1: Should the reference for 7250 be normative? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Ben Campbell's Yes on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)
Ben Campbell has entered the following ballot position for draft-ietf-tls-dnssec-chain-extension-06: 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-dnssec-chain-extension/ -- COMMENT: -- I am happy to see this published, but have a few minor comments: - I agree with Alexey's comments. -3.4: "If the TLSA record set was synthesized by a DNS wildcard, the chain must include the signed NSEC or NSEC3 records that prove that there was no explicit match of the TLSA record name and no closer wildcard match." Should that "must" be a "MUST"? - Nit in Authors List: Unless I've missed something, Richard's affiliation is no longer current. (I only point it out in case it's an oversight; I have no objection if it's that way on purpose.) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Ben Campbell's Yes on draft-ietf-tls-tls13-26: (with COMMENT)
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.) §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? §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. §D.5: This section has a lot of normative requirements that seem important. I wonder why it has been relegated to an appendix. *** 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". §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? §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? §E.2.1: [BDFKPPRSZZ16] : Best citation anchor evar ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Ben Campbell's Yes on draft-ietf-tls-tls13-26: (with COMMENT)
> On Mar 7, 2018, at 2:49 PM, Sean Turner wrote: > > > >> On Mar 6, 2018, at 12:27, Ben Campbell 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. > >> §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” > > 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? > >> §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 ServerHel
[TLS] Ben Campbell's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)
Ben Campbell has entered the following ballot position for draft-ietf-tls-ecdhe-psk-aead-04: No Objection 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-ecdhe-psk-aead/ -- COMMENT: -- I support Ekr's DISCUSS position. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
