On Wed, Mar 7, 2018 at 7:27 AM, Alexey Melnikov <aamelni...@fastmail.fm> wrote:
> Hi Ekr, > > On Wed, Mar 7, 2018, at 2:16 PM, Eric Rescorla wrote: > > > > On Wed, Mar 7, 2018 at 5:29 AM, Alexey Melnikov <aamelni...@fastmail.fm> > wrote: > > 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.) > > > > The intent is that these affect old TLS 1.2 implementations as well. S 1.4 > tries > to be clear about this, but maybe it fails. > > I suggest we: > > (1) Add the following sentence to the abstract: > "This document also specifies new requirements for TLS 1.2 implementations. > > (2) Rewrite the first sentence of S 1.4 to say: > This document defines several changes that optionally affect > implementations of TLS 1.2, including those which do not also > support TLS 1.3 > > (3) Strike the following graf: > > An implementation of TLS 1.3 that also supports TLS 1.2 might need to > include changes to support these changes even when TLS 1.3 is not in > use. See the referenced sections for more details. > > I think this will address my concern. > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1) On page 47: > The length of the salt MUST be equal to the length of the digest > algorithm > > Length of algorithm? > > > Right. Output of. > > > > > 2) DER need a Normative Reference on first use. There are some references > on > 2nd/3rd use. > > > Thanks. > > > > 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. > > > We do mean discard. The idea here is that you try to decrypt those records > using the handshake keys and if that fails you ignore them. > > > Ok. So I suggest use "discard" and possibly delete or reword the "untill > it is able" part. Maybe split into 2 sentences? > Sure, I can do something 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)? > > > No, you can't write application data prior to this point, as stated in S 2. > > Application data MUST NOT be sent prior to sending the Finished > message and until the record layer starts using encryption keys. > Note that while the server may send application data prior to > receiving the client's Authentication messages, any data sent at that > point is, of course, being sent to an unauthenticated peer. > > It's non-application data (handshake, alerts, acks) which is sent in this > fashion > prior to the handshake. > > > Ok. Maybe say that in the document. > OK, I'll try to clarify this. > > 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 > > > I concur. Thanks. > > > > 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. > > > This is in the first paragraph after the diagram. Would you prefer it > elsewhere? > > If a given secret is not available, then the 0-value consisting of a > string of Hash.length bytes set to zeros is used. Note that this > > > Maybe it was lack of sleep, but I didn't understand that you were talking > about the same thing. This also seems to apply more generically then on the > diagram. I suggest clarify: > > In the diagram, the value '0' denotes a string of Hash.length bytes set > to zeros. > > Or something like that. > Sure. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
