Re: [TLS] Alexey Melnikov's Discuss on draft-ietf-tls-tls13-26: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

On Wed, Mar 7, 2018 at 6:16 AM, Eric Rescorla <[e-mail]> wrote:

>
>
> On Wed, Mar 7, 2018 at 5:29 AM, Alexey Melnikov <[e-mail]>
> 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 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.
>
> I added some text.

>
>
> 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
>

I believe I dealt with this.

-Ekr


> -Ekr
>
>
>