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

[Martin Thomson]

On 2 November 2016 at 15:57, Watson Ladd  wrote:
> A conforming client will not produce Client Hellos that trigger
> multiple HRRs: it will listen the first time.

Good point. And most clients will elicit none.  I don't know how to
force this one into a failure to interoperate without taking the
approach Adam did with roughtime, and that's a tough call to make.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Tue, Nov 1, 2016 at 9:30 PM, Martin Thomson  wrote:
> On 2 November 2016 at 02:45, Watson Ladd  wrote:
>>
>> 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)
>
> failure to interoperate >> violate the spec
>
> I know that NSS rejects multiple HRRs.  I expect that Boring does too
> (couldn't be bothered to check).  That means you have to be even
> lazier than I am with interop testing to make this mistake :)

A conforming client will not produce Client Hellos that trigger
multiple HRRs: it will listen the first time.


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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

On 2 November 2016 at 02:45, Watson Ladd  wrote:
>
> 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)

failure to interoperate >> violate the spec

I know that NSS rejects multiple HRRs.  I expect that Boring does too
(couldn't be bothered to check).  That means you have to be even
lazier than I am with interop testing to make this mistake :)

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Mon, Oct 31, 2016 at 2:28 PM, Eric Rescorla  wrote:
> Watson,
>
> Thanks for your comments!
>
> On Mon, Oct 31, 2016 at 11:41 AM, Watson Ladd  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

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

[Eric Rescorla]

Watson,

Thanks for your comments!

On Mon, Oct 31, 2016 at 11:41 AM, Watson Ladd  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.


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?


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?


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?


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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Mon, Oct 31, 2016 at 11:41:46AM -0700, Watson Ladd wrote:

> 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. The mandated use of uncompressed
> points invites easy wrong-curve attacks: mandating support and use for
> compressed points would solve this problem. I think at minimum we
> should fix the text to make clear what we mean about TLS 1.2.

Just as note: Point compression does not completely fix wrong-curve
attacks.

The reason is that for Weierstrass curves and the usual square square
root algorithm, the "square roots" for QNRs, if the code does not check,
don't result points on the twist, but all sorts of strange points, on
variety of different curves.

(With one-coordinate Montgomery ladder on montgomery curves, the invalid
points all map to the twist, which is a single curve and can be arranged
to have a large prime factor in its order).

Oh, and thanks to different message order in TLS 1.3 compared to TLS
1.2, wrong-curve attacks look more exploitable.

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

Well, the spec prohibits accepting 0-RTT data if ALPN does not match,
but this looks bit error prone to me.

I proposed forcing the ALP to the previous value, and not allowing it
to be negotiated via any method. This would eliminate this sort of
edge case check.

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

I think this is a replacement for the tls-unique channel binding. While
the definition of tls-unique does still make sense for TLS 1.3, the
definition has security problems with TLS 1.2.

Thus, need for replacment.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls