Re: [TLS] Alexey Melnikov's Discuss on draft-ietf-tls-tls13-26: (with DISCUSS and COMMENT)
On Wed, Mar 7, 2018 at 6:16 AM, Eric Rescorla wrote: > > > On Wed, Mar 7, 2018 at 5:29 AM, Alexey Melnikov > 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. > > > > >> >> -- >> 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. > I just double-checked and this actually is: under ECDSA. > > >> >> 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. > > >> 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 effe
Re: [TLS] Alexey Melnikov's Discuss on draft-ietf-tls-tls13-26: (with DISCUSS and COMMENT)
On Wed, Mar 7, 2018 at 7:27 AM, Alexey Melnikov 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 > 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
Re: [TLS] Alexey Melnikov's Discuss on draft-ietf-tls-tls13-26: (with DISCUSS and COMMENT)
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 > 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? > >> >> 4) On page 82: >> >> When record protection has not yet been engaged, TLSPlaintext >> str
Re: [TLS] Alexey Melnikov's Discuss on draft-ietf-tls-tls13-26: (with DISCUSS and COMMENT)
On Wed, Mar 7, 2018 at 5:29 AM, Alexey Melnikov 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. > > -- > 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. > 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 ke
