Subject: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

From: Brian Smith <[email-masked]>
Date: Tue, 22 Dec 2015 11:14:47 -1000

The current draft [1] says:

    Other than this recommended check, implementations do
    not need to ensure that the public keys they receive
    are legitimate: this is not necessary for security
    with Curve25519.

However, Thai Duong (of BEAST fame, among other things) wrote that TLS 1.2
and below do seem to benefit from public key validation in "Why not
validate Curve25519 public keys could be harmful" [2]. Watson Ladd had also
pointed out many times on this list that TLS is one protocol where
contributory behavior is required.

DJB himself had also pointed out did point out that some protocols do
require public key validation with Curve25519 "to ensure 'contributory'
behavior" in [3]. Thus, the statement in draft-ietf-tls-curve25519-01 that
"this is not necessary for security with Curve25519" in the current draft
is clearly overly general and misleading.

In particular, I noticed that the text in draft-ietf-tls-curve25519-01
section 2.3 focuses a lot on attacks that reveal the private key. However,
what about other attacks? In particular, I think that, at the very least,
the relevance or irrelevance to TLS of the key dictation attack that Thai
brought up, and the need or non-need for checking that the agreed value is
zero (basically the same thing), should be mentioned in the draft's
security considerations.

[1] https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3
[2]
http://vnhacker.blogspot.com/2015/09/why-not-validating-curve25519-public.html
[3] http://cr.yp.to/ecdh.html#validate

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Watson Ladd <[email-masked]>
Date: Tue, 22 Dec 2015 16:51:40 -0500

On Dec 22, 2015 4:15 PM, "Brian Smith" <[email-masked]> wrote:
> However, Thai Duong (of BEAST fame, among other things) wrote that TLS
1.2 and below do seem to benefit from public key validation in "Why not
validate Curve25519 public keys could be harmful" [2]. Watson Ladd had also
pointed out many times on this list that TLS is one protocol where
contributory behavior is required.

Textbook DH does not ensure contributory behavior. Applications don't
implement the required checks for poorly designed protocols. If we insert
checks, applications which fail to make those checks will be vulnerable,
while fixing protocols closes the hole.
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Dec 2015 10:16:47 +1100

> while fixing protocols closes the hole.

I've done a fair bit of reading into this issue as well, finding
Thai's blog posting and a few other things.  As Watson says, the
protocol can be designed so that it doesn't depend on the DH exchange
providing contributory behaviour.  We should definitely do that either
way.

I understand that the checks are considered onerous by some, but I
still don't understand why anyone might refuse to do them.  Checking
that you don't get a bad output from the DH computation is a tiny
piece of code that takes almost no time at all, even if you have to
worry about doing it in constant time.

---

From: Brian Smith <[email-masked]>
Date: Tue, 22 Dec 2015 13:23:53 -1000

Martin Thomson <[email-masked]> wrote:

> Watson Ladd <[email-masked]> wrote:

TLS 1.2 and earlier versions are already defined. So, fixing the protocol
is a good solution for TLS 1.3 and later, but draft-ietf-tls-curve25519
also is supposed to work for the versions that can't be fixed.

> worry about doing it in constant time.

To be clear, I'm not arguing that the draft should recommend or require
such a check. Merely, I'm pointing out that we have the following
contradictions that the draft doesn't resolve:

1. The draft says that Curve25519 doesn't require public key validation,
full stop.
2. DJB said that Curve25519 may require public key validation for protocols
that require contributory behavior.
3. Thai and Watson both said that TLS 1.2 and earlier require contributory
behavior.

It may be the case that TLS requires contributory behavior and point
validation is still unnecessary. Or, it may be the case that TLS doesn't
really require contributory behavior (though, it seems obvious to me that
it does, at least for TLS 1.2 and earlier). Or, it may be the case that TLS
requires contributory behavior and a check is necessary. The draft should
make it clear which case we are dealing with, with a reference to the
reasoning that gave us whatever conclusion is reached, but currently that
is missing.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Dec 2015 10:29:27 +1100

On 23 December 2015 at 10:23, Brian Smith <[email-masked]> wrote:
> really require contributory behavior (though, it seems obvious to me that it
> does, at least for TLS 1.2 and earlier). Or, it may be the case that TLS
> reasoning that gave us whatever conclusion is reached, but currently that is
> missing.

My understanding is that with session hash TLS 1.2 is OK, as is 1.3.
Like Watson and Thai, I think that 1.2 without session hash is not OK.

That suggests that the 25519 draft should require session hash in 1.2.

---

From: Brian Smith <[email-masked]>
Date: Tue, 22 Dec 2015 14:09:32 -1000

> That suggests that the 25519 draft should require session hash in 1.2.

If an implementation only implements ECDHE cipher suites then implementing
the session hash extension is not necessary, according to RFC 7627. I
believe there are also a few other factors that would implementing the
session hash extension to be unnecessary.

If checking that the shared value isn't zero is sufficient, and/or
blacklisting the public values that DJB mentions in [1] is sufficient,
either would be better than mandating the implementation of the session
hash extension just for this purpose.

[1] http://cr.yp.to/ecdh.html#validate

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 23 Dec 2015 01:13:03 +0000

On Tue, Dec 22, 2015 at 02:09:32PM -1000, Brian Smith wrote:

> If checking that the shared value isn't zero is sufficient

It should suffice, ideally with a constant-time comparison.

-- 
	Viktor.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Dec 2015 12:32:08 +1100

> the session hash extension is not necessary, according to RFC 7627. I

It doesn't really say that as far as I can see, though I guess that
you could infer that from this statement:

   Handshakes using Ephemeral
   Elliptic Curve Diffie-Hellman (ECDHE) ciphersuites are also
   vulnerable if they allow arbitrary explicit curves or use curves with
   small subgroups.

---

From: Brian Smith <[email-masked]>
Date: Tue, 29 Dec 2015 09:05:17 -1000

On Tue, Dec 22, 2015 at 2:09 PM, Brian Smith <[email-masked]> wrote:

> If an implementation only implements ECDHE cipher suites then
> implementing the session hash extension is not necessary, according to RFC
> 7627. I believe there are also a few other factors that would implementing
> the session hash extension to be unnecessary.
>

Actually, the check for a result of zero is already required in the current
CFRG draft; see [1]. So, I think that the easiest way to fix the TLS draft
is to just delete the misleading text.

[1] https://tools.ietf.org/html/draft-irtf-cfrg-curves-11#section-6.1

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Tue, 29 Dec 2015 22:10:47 +0200

As mentioned before, validating Curve25519 public values is necessary in TLS 1.2 without session hash.
Otherwise, as we pointed out in [1], the triple handshake attack returns.

[1] http://www.internetsociety.org/doc/verified-contributive-channel-bindings-compound-authentication <http://www.internetsociety.org/doc/verified-contributive-channel-bindings-compound-authentication>

> On 29 Dec 2015, at 21:05, Brian Smith <[email-masked]> wrote:
> 
> On Tue, Dec 22, 2015 at 2:09 PM, Brian Smith <[email-masked] <mailto:[email-masked]>> wrote:
> If an implementation only implements ECDHE cipher suites then implementing the session hash extension is not necessary, according to RFC 7627. I believe there are also a few other factors that would implementing the session hash extension to be unnecessary.
> 
> If checking that the shared value isn't zero is sufficient, and/or blacklisting the public values that DJB mentions in [1] is sufficient, either would be better than mandating the implementation of the session hash extension just for this purpose.
> 
> Actually, the check for a result of zero is already required in the current CFRG draft; see [1]. So, I think that the easiest way to fix the TLS draft is to just delete the misleading text.
> 
> [1] https://tools.ietf.org/html/draft-irtf-cfrg-curves-11#section-6.1 <https://tools.ietf.org/html/draft-irtf-cfrg-curves-11#section-6.1>
> Cheers,
> Brian
> --
> https://briansmith.org/ <https://briansmith.org/>
>

---

From: Kurt Roeckx <[email-masked]>
Date: Wed, 30 Dec 2015 11:52:07 +0100

> Otherwise, as we pointed out in [1], the triple handshake attack returns.

Would it make sense to have session hash as a requirement in TLS
1.2 when you want to use Curve25519?

Kurt

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 30 Dec 2015 13:10:51 +0200

> is to just delete the misleading text.

The RFC4492bis draft already species that peer must abort on zero output.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 30 Dec 2015 13:16:31 +0200

> 1.2 when you want to use Curve25519?

I don't think that is reasonable.

The RFC4492bis document could point out the consequences of omitting
the zero check (which is already REQUIRED) in the security
considerations tho.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 Dec 2015 09:55:10 +1100

> I don't think that is reasonable.

I think that is entirely reasonable.  TLS 1.2 relies on contributory
behaviour.  25519 doesn't provide that unless you do some extra
checking that we know many implementations don't do.

I'd be OK with either requiring session hash, some checking of values,
or both.  Otherwise we create a situation where the shared secret can
be forced by an attacker.

---

From: Brian Smith <[email-masked]>
Date: Wed, 30 Dec 2015 13:54:27 -1000

> checking that we know many implementations don't do.

The check for zero is not "extra". It is required by the CFRG draft spec.

Here's my proposed rewrite of this section:

2.3.  Public key validation

   draft-irtf-cfrg-curves-11 specifies how to do the Diffie-Hellman
   computation and the checks that are required.

   Note in particular that [I-D.irtf-cfrg-curves Section 6.1] and
   [I-D.irtf-cfrg-curves Section 6.2] require implementations to
   check, in a side-channel-safe manner, that the result of the
   Diffie-Hellman computation is non-zero. Such a check is essential
   for preventing key dictation attacks in TLS, as described in
   [Contributive Section III.b.3].

   Implementations MAY check that the peer's public value u-coordinate
   is on the curve, but such a check is not necessary when the check
   for a non-zero result is done. The practical consequence of this is
   that public u-coordinates must be reduced modulo the field order
   as required in draft-irtf-cfrg-curves-11 before being transmitted.

[Contributive]
           Bhargavan, K, A. Delignat-Lavaud, and A. Pironti. "Verified
           Contributive Channel Bindings for Compound Authentication",
           Feb 2015,
           <https://www.internetsociety.org/sites/default/files/08_5.pdf>.

I am not sure if [Contributive] is the best reference, but it is the only
one I know of that actually addresses the issue specifically for TLS and
these curves.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Brian Smith <[email-masked]>
Date: Wed, 30 Dec 2015 14:03:50 -1000

> 1.2 when you want to use Curve25519?

I think it is a good idea to implement the session hash extension, in
general. However, I think it is a bad idea to prescribe it as the solution
for this particular problem because:

1. draft-irtf-cfrg-curves-11, in sections 6.1 and section 6.2 already
require the check for a non-zero result, and that check is sufficient.

2. It is easy to make an automated test that verifies that an X25519/X448
implementation implements the non-zero check. Adding an automated test for
conditional enabling of them based on the presence of the session hash
extension is much harder.

3. It is much less error-prone to implement the non-zero result check than
to make the availability of X25519/X448 depend on whether or not the
session hash extension is implemented. Experience, e.g. [1], has shown that
such conditional enabling is error-prone.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=919677

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 31 Dec 2015 02:08:03 +0200

> be forced by an attacker.

The draft already has the checks.

I also think I figured out a way to truly force contributory behaviour
without any checks:

It is a bit nasty hack: Throw the exchange keys into the PMS, expanding
it from 32/56 bytes to 96/168 bytes.

-Ilari

---

From: Watson Ladd <[email-masked]>
Date: Wed, 30 Dec 2015 19:23:12 -0500

> it from 32/56 bytes to 96/168 bytes.

Why not hash the public values into the result of the key exchange? I don't
want security to depend on omittable checks.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Dec 2015 19:30:13 -0500

On Wed, Dec 30, 2015 at 7:23 PM, Watson Ladd <[email-masked]> wrote:

> Why not hash the public values into the result of the key exchange? I
> don't want security to depend on omittable checks.
>
Note that session-hash does this, so it seems best to use session-hash if
you want
to adopt this strategy.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 31 Dec 2015 02:32:20 +0200

> want security to depend on omittable checks.

What values you think are realistically available at that point, other than
the exchange public keys?

-Ilari

---

From: Brian Smith <[email-masked]>
Date: Wed, 30 Dec 2015 14:47:20 -1000

> don't want security to depend on omittable checks.

One would need an omittable check in the code to decide whether to do that
extra hashing, so that wouldn't solve the (non-)problem of "omittable
checks".

Similarly, one would need an omittable check to decide whether to require
the session hash extension, so it wouldn't solve the (non-)problem of
"omittable checks".

Actually, because the check for non-zero result can/should/is in the
X25519/X448 functions themselves, the check for non-zero result is the
least likely of all these possible solutions to be omitted. And, it is also
the easiest to test.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Watson Ladd <[email-masked]>
Date: Wed, 30 Dec 2015 21:16:12 -0500

On Wed, Dec 30, 2015 at 7:47 PM, Brian Smith <[email-masked]> wrote:
> X25519/X448 functions themselves, the check for non-zero result is the least
> likely of all these possible solutions to be omitted. And, it is also the
> easiest to test.

Failure to compute H(A, B, X25591(a, B)) would result in an
interoperability failure with any other implementation of this
ciphersuite. By contrast a zero check will not be exercised by basic
interoperability testing, nor would mandatory use of session hash.

All currently existing implementations of the X25519 function do not
perform zero checks. Ones that do have to return a value, which can
easily be ignored. Short of calling abort there is no way for
implementors of cryptographic functions to ensure that callers pay
attention to return values.

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

---

From: Adam Langley <[email-masked]>
Date: Wed, 30 Dec 2015 19:30:08 -0800

> require the check for a non-zero result, and that check is sufficient.

As discussed on the CFRG list, the plan is that the final curves RFC
will say that the zero check is a MAY. (See
https://www.ietf.org/mail-archive/web/cfrg/current/msg07611.html)

I don't mind if the integration of curve25519 in TLS requires a
zero-check or not, but what property are people hoping to gain? If one
wants to avoid triple-handshake like issues then session-hash is the
answer. A client can use an RSA key exchange to control the PMS
completely, of course, and, with finite-field DH, a value of zero or
p-1 will usually allow the same.

Cheers

AGL

---

From: Brian Smith <[email-masked]>
Date: Wed, 30 Dec 2015 17:40:52 -1000

> https://www.ietf.org/mail-archive/web/cfrg/current/msg07611.html)

When you say "the plan," whose plan are you referring to? If you read that
whole thread, there was a lot of well-founded opposition to that plan. And,
that plan was never carried out. That is plain to see, as there was never a
draft submitted with such a change. So, I assumed that "the plan" was
dropped. This isn't a minor editorial change, so it wouldn't be appropriate
(IMO) to have the final spec changed in this respect without having had
that change reflected in any draft that people have actually been reviewing.

> answer.

Session Hash is *an* answer, but, for the reasons I already gave in this
thread, it isn't the best answer for this.

A client can use an RSA key exchange to control the PMS
> p-1 will usually allow the same.

Not if the implementation doesn't implement RSA or finite-field DH.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Alyssa Rowan <[email-masked]>
Date: Thu, 31 Dec 2015 06:23:08 +0000

On 2015-12-31 03:30, Adam Langley wrote:

> zero-check or not, but what property are people hoping to gain? If
> one wants to avoid triple-handshake like issues then session-hash
> is the answer.

(I have a terrible cold, so apologies if I am less than coherent!)

I think I prefer this, of the available options. Specify that:

• Both client and server MUST abort if X25519 and/or X448 are
  offered/chosen but session_hash is not;
• Explain why in Security Considerations;
• Test as part of interop/unit tests?

Zero checks are more likely to be omitted in practice because all the
implementations out there already do that and don't return a value.
And it's not something the peer would notice in normal operation.

Watson's approach might work too, but of the available options I think
ensuring the transcript is hashed is the most robust with respect to
any future attacks.

- -- 
/akr

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 31 Dec 2015 01:51:02 -0500

On Thu, Dec 31, 2015 at 1:23 AM, Alyssa Rowan <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>

I think the above sets up a situation where the safer curves are tied
to 0-RTT and friends. I'm pretty sure any configuration under my
purview will *not* have 0-RTT enabled. My servers will *not* be
consuming data before it has been authenticated.

I can only say I'm "pretty sure". I won't know for certain until I
actually step the code under a debugger and see what is being consumed
in the negative cases.

My apologies if I am parsing it incorrectly or going against the grain.

Jeff

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 31 Dec 2015 08:54:51 +0200

> And it's not something the peer would notice in normal operation.

The problems with this:

The THS check is a check.

Zero checks can already be unit-tested/interop-tested just as well.

If you do anything that is vulernable to THS, you better take severe
countermeasures at application layer (check for EMS, mix in certs,
refuse resumption, dump and hash transcripts, etc...) already.

As for reliability of using ECDHE... I wouldn't rely that random
implementation of ECDHE is safe against THS, even with cofactor 1
Weierstrass curves. And unit-testing/interop-testing some of the
issues involved is just plain nasty.

> ensuring the transcript is hashed is the most robust with respect to

Actually, I proposed something very similar, but without a hash (HMAC
would likely hash that thing anyway[1]). That one does not have any
checks.

[1] Specifically, unless X25519 is used with ciphersuite with SHA-384
as PRF-hash.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Dec 2015 07:54:33 -0800

I'm finding myself a bit unclear on the scenario people are concerned about.

It seems like there are two potential cases:

1. You have an implementation which already does some of the algorithms
we know are susceptible to THS-type attacks.
2. You have an implementation which only does the CFRG curves.

In the first case, if you are in a scenario where THS is relevant, then you
should be insisting on session hash for the existing algorithms and so it's
simplest to just always insist on session hash. And if you're failing to
do so, then it's not clear to me how having the CFRG curves be safe
here helps (it might be true, but I haven't convinced myself of it.)

In a previous thread, Brian suggested an implementation that was just
CFRG curves, so perhaps that's the scenario of interest? But in that case
you can just *only* implement session hash. Specifically, you insist on
negotiating the extension but only implement the session hash key
derivation,
rather than the normal key derivation, so there's not really a check to
omit [0].

Am I missing something?

-Ekr

[0] This is effectively how 1.3 behaves by just always requiring session
hash.

---

From: Adam Langley <[email-masked]>
Date: Thu, 31 Dec 2015 09:43:42 -0800

On Wed, Dec 30, 2015 at 7:40 PM, Brian Smith <[email-masked]> wrote:
> draft submitted with such a change.

I'm no expert on IETF processes but the draft was already in a late
stage at the time when that came up and I think it was last the point
for a -12? The revision that's currently in AUTH48 with the RFC Editor
contains the change from MUST to MAY.

> Not if the implementation doesn't implement RSA or finite-field DH.

I think ekr's post, just previous, reflects my understanding here. For
the vast majority of implementations, session-hash is needed because
non-contributory key-exchange mechanisms will be included. If you do
happen to have an implementation that only implements ECDHE with
cofactor 1 curves or X25519 or X448, then I guess you could get away
without implementing session hash, but I'd still implement session
hash anyway.

Having said that, I think I'd be fine with a TLS draft that said that
the zero check should (or must) be done because I think that it should
be done in general.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Dec 2015 09:50:37 -0800

> without implementing session hash, but I'd still implement session

FWIW, I don't believe that it's significantly harder to implement TLS w/
session
hash than TLS w/o session hash. You have to do the extension but since
you can just fail any handshake in which it's not offered, this isn't that
bad.
What's expensive is supporting *both* session hash and non session hash
(at least that's what we found in NSS).

> the zero check should (or must) be done because I think that it should

As would I.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Fri, 1 Jan 2016 06:22:00 +1100

> Zero checks can already be unit-tested/interop-tested just as well.

What ekr said applies, but also this:

Yes, you can test that a given implementation does the right checks,
but you won't be checking during normal operation.  If you require
session-hash, then every handshake includes that check and if someone
messes up, the handshake just fails.  That far more visible.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 31 Dec 2015 22:20:43 +0200

> What ekr said applies, but also this:

I thought the ekr's point was that if you need THS resistance, you
require EMS. If you don't, not much point worrying what properties
individual key exchanges have.
 
> messes up, the handshake just fails.  That far more visible.

I don't think the parts that actually matter are tested in normal
use. Unless you mean deimplementing entiere old TLS master secret
derivation...

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Dec 2015 12:23:50 -0800

> individual key exchanges have.

I think I was trying to say *almost* this: Namely that given that we have
existing
mechanisms that rely on EMS for THS resistance, and most stacks will
continue
to use them, then it's easier to just require EMS.

> use. Unless you mean deimplementing entiere old TLS master secret

What I was suggesting was that:

1.  Implementations which support old algorithms need to have EMS for THS
resistance already.

2. Implementations which only do new algorithms can mandate EMS and not
implement old derivation at all, provided we make that a rule here.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 31 Dec 2015 22:46:05 +0200

> interoperability testing, nor would mandatory use of session hash.

Actually, I figured out an attack. Which also breaks my original scheme
(except in one rare case).

A hack to break that attack would be to zero-pad the hash output to
minimum of 48 bytes and then to append (prepending won't work)
something nonzero (e.g the group id, that is 00 29 for X25519 and
00 30 for X448).

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 31 Dec 2015 22:49:58 +0200

> implement old derivation at all, provided we make that a rule here.

Well, the EMS spec already says that endpoints SHOULD abort if
extension is not present if they don't want to interop with
legacy implementations.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Dec 2015 12:55:09 -0800

> extension is not present if they don't want to interop with

Correct. But as you say, that's a check that you can omit. However, if you
only
implement the EMS derivation than (unless I'm missing something) even if you
omit the check this should just result in a handshake failure.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 31 Dec 2015 23:47:05 +0200

> omit the check this should just result in a handshake failure.

Yes, if you don't want to interop with legacy implementations, don't
implement the legacy key derivation.

Unfortunately, I think I figured out that client requiring ECDHE
even with only NIST curves with full checking (which is contributory
if that is even possible) does _not_ prevent THS attacks.

So, if the protocol run on TLS does not resist THS attacks anyway
somehow, you MUST require EMS.

-Ilari