Re: [TLS] Comments on draft-ietf-tls-tls13-18

[Watson Ladd <[e-mail]>]

On Mon, Oct 31, 2016 at 2:28 PM, Eric Rescorla <[e-mail]> wrote:
> Watson,
>
> Thanks for your comments!
>
> On Mon, Oct 31, 2016 at 11:41 AM, Watson Ladd <[e-mail]> wrote:
>>
>> Hello,
>>
>> Looking at the history of TLS implementation attacks we see that many
>> result from the standard not strictly enough prescribing behavior,
>> particularly of the state machine. This draft does not actually fix
>> this problem, but continues to present example flows without
>> explicitly requiring them to be the only possible flows.
>
>
>
>> For example, consider HelloRetryRequest. Do servers only send one of
>> these per connection, or can it be resent multiple times? Obviously
>> there is a DoS possibility here, but I do not see where this behavior
>> is explicitly defined. I think we should require that the server only
>> ever sends one HelloRetryRequest, and then terminates the connection
>> if the ClientHello is unacceptable.
>
>
>
> The server is forbidden to send multiple HRRs and the client is required
> to enforce it. See:
>
>   https://tlswg.github.io/tls13-spec/#hello-retry-request
>
> I agree that we don't require the server to behave this way. I can fix the
> draft to say this.

That sounds good. The more we can turn bugs into ones that violate the
spec, the easier it will be to get them fixed. (Hopefully)

>
>
>> At no point is it stated that only
>> the example flows should be supported. I would prefer more clarity
>> about what messages are to be expected when, especially with alerts.
>
>
> Actually the text does say something here:
> https://tlswg.github.io/tls13-spec/#handshake-protocol
>
> "Protocol messages MUST be sent in the order defined below (and shown in the
> diagrams in Section 2). A peer which receives a handshake message in an
> unexpected order MUST abort the handshake with an “unexpected_message”
> alert. Unneeded handshake messages are omitted, however."
>
> However, this text was also in 5246, so I think there's a fair argument
> that it's not strong enough. I'm not quite sure how to make it better.
> Suggestions?

So I was reading in order, so I saw the diagrams first, which seemed
like examples and then missed this sentence in the draft. Maybe a
sentence in section 2 would help?

>
>
>> ECDSA cannot be used with x25519 or x448, but the draft seems to
>> require support in TLS 1.2 for this as a consequence of its
>> description of the fallback mode.
>
>
> I don't *think* that that's true: can you point to the specific text that
> you are concerned with?

It's the interaction between
https://tlswg.github.io/tls13-spec/#negotiated-groups and the
statement that ECDSA needs to be supported with any curve appearing in
the supported_groups extension when negotating a TLS 1.2 hello. We
explicitly call x25519 an elliptic curve there. Yes, I doubt anyone
will end up making an implementation that does this (except by
accident).

>
>
>> ALPN, resumption, and 0-RTT remain problematic. For instance we see
>> that 0-RTT data is sent with the same ALPN state when the PSK was
>> derived, but this could be different from the ALPN transmitted and
>> negotiated during the handshake, which is explicitly allowed later in
>> the document. I do not understand what is supposed to happen in this
>> scenario.
>
>
> Here's the relevant text:
> https://tlswg.github.io/tls13-spec/#early-data-indication
>
> "If any of these checks fail [ALPN is in the list above] the server MUST NOT
> respond with the extension and must discard all the remaining first flight
> data (thus falling back to 1-RTT). If the client attempts a 0-RTT handshake
> but the server rejects it, it will generally not have the 0-RTT record
> protection keys and must instead trial decrypt each record with the 1-RTT
> handshake keys until it finds one that decrypts properly, and then pick up
> the handshake from that point."
>
> Is there anything else you'd like to see here?
>
>> Appendix B removes the text about upper-layer protocol interactions
>> with 0-RTT I provided, merely discussing the API. I think this is a
>> mistake: how 0-RTT should be used safely depends on the upper-layer
>> protocol, and can be complex. API guidance is not enough.
>
>
> This ended up in the main text:
> https://tlswg.github.io/tls13-spec/#zero-rtt-data
>
> "Protocols MUST NOT use 0-RTT data without a profile that defines its use.
> That profile needs to identify which messages or interactions are safe to
> use with 0-RTT. In addition, to avoid accidental misuse, implementations
> SHOULD NOT enable 0-RTT unless specifically requested. Special functions for
> 0-RTT data are RECOMMENDED to ensure that an application is always aware
> that it is sending or receiving data that might be replayed."
>
> Is this missing pieces you think we need?

Yes, thanks for pointing out where I missed it.
>
>
>> There is still a note about needing a channel binding mechanism in the
>> text. I think this should be resolved soon so it can be analyzed,
>> probably built on top of the exporter mechanism. Either that, or we
>> consciously punt and remove the note and replace with something else.
>
>
> The idea here is that we need a separate draft that just says "use exporters
> with
> label X". I think we remove the note and see if we can get someone to write
> that draft.
>
>
>> As for process, I support the idea of having a last call on November
>> 20th, and then completing the security analysis by January 20th (or
>> whatever date was decided). This will prevent a flurry of changes
>> potentially breaking things.
>
>
> That's the idea.
>
> -Ekr
>
>>
>> Sincerely,
>> Watson Ladd
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>
>



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.