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

[Ilari Liusvaara <[e-mail]>]

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