Subject: [TLS] Early code point assignment for draft-ietf-tls-curve25519-01

From: Joseph Salowey <[email-masked]>
Date: Sun, 10 Jan 2016 19:53:08 -0800

Please respond if you have concern about early code point assignment for
the curves listed in draft-ietf-tls-curve25519-01
<https://tools.ietf.org/html/draft-ietf-tls-curve25519-01>.

Thanks,

J&S

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 11 Jan 2016 09:28:57 +0200

> <https://tools.ietf.org/html/draft-ietf-tls-curve25519-01>.

Wasn't that document effectively merged to RFC4492bis?

Also, one contention point in recent thread has seemed how to deal
with THS. Basically, in the basic variant, there is a check (specified
as MUST) that partially mitigates THS (without EMS) to the level of
P-256 (and to level stronger than P-384 for X448). But if omitted, THS
attacks are easy (assuming no EMS).

I did look at if it would be possible to modify PMS derivation to
render it immune to THS without requiring any checks nor touching
MS derivation. The answer turned out to be negative (through some
variants, like the SHA512(A|B|DH(A,B)) one were impossible to
exploit given some reasonable-sounding extra assumptions)..

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 11 Jan 2016 10:03:18 +0200

On Mon, Jan 11, 2016 at 09:28:57AM +0200, Ilari Liusvaara wrote:
> with THS.

And as terms of my current position on this:

I don't think this is signficant. If you want protection from THS that
actually works, you require EMS anyway (or ensure THS is of no
consequence at application layer), not try to do TLS configuration
"workarounds" (that don't actually work).

-Ilari

---

From: Watson Ladd <[email-masked]>
Date: Mon, 11 Jan 2016 00:12:47 -0800

> "workarounds" (that don't actually work).

Are you saying that a Suite B only deployment of TLS which does point
validation is THS vulnerable? I also don't see what attack on
SHA512(A|B|DH(A,B)) needs extra assumptions to be prevented.

>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 11 Jan 2016 10:30:23 +0200

On Mon, Jan 11, 2016 at 12:12:47AM -0800, Watson Ladd wrote:
> validation is THS vulnerable?

If both ends are Suite B only, highly unlikely... However, things get
more exciting (as in "exciting crypto") if one end is and the other
isn't...

(Suite B isn't special here, there are other possible profiles
with similar properties).

-Ilari

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 12 Jan 2016 10:24:09 +0100

> <https://tools.ietf.org/html/draft-ietf-tls-curve25519-01>.

The above draft, and rfc4492bis and tls13-11, has known
issues/inconsistencies related to X25519/X448 that have been discussed
on the list.  When it was decided (offlist..) to move the content of
draft-ietf-tls-curve25519 to other documents, I stopped working on it.

What would the semantics of these code points related to the known
issues be (e.g., code point validation or not)?  Do the code points
refer to what the draft above says, or what people appear to prefer
(don't reject, but ignore set bit) and have been implementing?

I can update the document to fix the known issues.  The content has been
copied to other documents that I have no editor influence of, so
modifying draft-ietf-tls-curve25519 may make the situation even more
confusing.  Please advice if you want anything more to happen with the
document above.

/Simon