Alexey Melnikov has entered the following ballot position for draft-ietf-tls-tls13-26: Discuss
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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for a well written document. I will be switching to Yes once the following is addressed/discussed: Relationship to TLS 1.2 needs to be clarified. The document is adding requirements on TLS 1.2 clients. Implementors of TLS 1.2 are not going to (or very unlikely to) read this document. This looks fishy to me. Two examples on page 37: TLS 1.2 clients SHOULD also check that the last eight bytes are not equal to the second value if the ServerHello indicates TLS 1.1 or below and A legacy TLS client performing renegotiation with TLS 1.2 or prior and which receives a TLS 1.3 ServerHello during renegotiation MUST abort the handshake with a "protocol_version" alert. Note that renegotiation is not possible when TLS 1.3 has been negotiated. There are similar statements on page 45: TLS 1.2 implementations SHOULD also process this extension. and on page 48: However, the old semantics did not constrain the signing curve. If TLS 1.2 is negotiated, implementations MUST be prepared to accept a signature that uses any curve that they advertised in the "supported_groups" extension. I think you need to clarify whether these normative requirements apply to pure TLS 1.2 clients or TLS clients that implement both 1.2 and 1.3 and choose to use 1.2 for some reason. Or maybe you need to say in the Abstract/Introduction that although this document obsoletes TLS 1.2 it also specifies new requirements on TLS 1.2 implementations. (So it is sort of both "Obsoletes" and "Updates" TLS 1.2 RFC.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) On page 47: The length of the salt MUST be equal to the length of the digest algorithm Length of algorithm? 2) DER need a Normative Reference on first use. There are some references on 2nd/3rd use. 3) On page 57: The server then ignores early data by attempting to decrypt received records in the handshake traffic keys until it is able to receive the client's second flight and complete an ordinary 1-RTT handshake, skipping records that fail to decrypt, up to the configured max_early_data_size. I read this several times and still don't understand what this is saying. It is saying "ignores ... until it is able to receive". I think you either don't mean "ignore" (as in discard the rest) or I misunderstood. I clarifying example or a reference to another section (e.g. with the diagram) would be very helpful here. 4) On page 82: When record protection has not yet been engaged, TLSPlaintext structures are written directly onto the wire. Once record protection has started, TLSPlaintext records are protected and sent as described in the following section Just to double check: are you saying that before the handshake TLS application layer effectively results in plain text messages (with some extra octets to signal record type)? 5) I am pretty sure that [RFC5116] is a Normative reference. It is required to be understood to implemented TLS 1.3. Also, you have additional requirements on AEADs, which again implies understanding of what they are: On page 84: An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion greater than 255 octets and An AEAD algorithm where N_MAX is less than 8 bytes MUST NOT be used with TLS 6) The diagram in section 7.1 was a bit cryptic. Maybe explain that when you use '0' you mean as many bytes of 0s as needed for various functions. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
