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

[Brian Smith]

Adam Langley  wrote:

> On Wed, Dec 30, 2015 at 4:03 PM, Brian Smith  wrote:
>
> > 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.
>
> 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)
>

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.


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


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
> completely, of course, and, with finite-field DH, a value of zero or
> p-1 will usually allow the same.


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

Cheers,
Brian
-- 
https://briansmith.org/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Adam Langley]

On Wed, Dec 30, 2015 at 4:03 PM, Brian Smith  wrote:

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

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

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

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

[Jeffrey Walton]

On Thu, Dec 31, 2015 at 1:23 AM, Alyssa Rowan  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2015-12-31 03:30, Adam Langley wrote:
>
>> 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.
>
> (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?

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

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

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

[Ilari Liusvaara]

On Thu, Dec 31, 2015 at 06:23:08AM +, Alyssa Rowan wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2015-12-31 03:30, Adam Langley wrote:
> 
> > 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.
> 
> (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.

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.

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

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

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

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

[Watson Ladd]

On Wed, Dec 30, 2015 at 7:47 PM, Brian Smith  wrote:
> Watson Ladd  wrote:
>>
>> Why not hash the public values into the result of the key exchange? I
>> 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.

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.

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



-- 
"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] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

[Brian Smith]

Martin Thomson  wrote:

> On 30 December 2015 at 22:16, Ilari Liusvaara 
> wrote:
> >> Would it make sense to have session hash as a requirement in TLS
> >> 1.2 when you want to use Curve25519?
> >
> > 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.
>

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

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

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

[Brian Smith]

Kurt Roeckx  wrote:

> On Tue, Dec 29, 2015 at 10:10:47PM +0200, Karthikeyan Bhargavan wrote:
> > 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.
>
> Would it make sense to have session hash as a requirement in TLS
> 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/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] draft-ietf-tls-curve25519: Remove Appendix A

[Brian Smith]

I suggest that the entire Appendix A be removed, as it duplicates
draft-irtf-cfrg-curves-11 and it is too difficult and tedious to verify
that it matches what draft-irtf-cfrg-curves-11 says.

Also, it doesn't say anything about X448. I've noticed that the draft has a
few other places that talk specifically about Curve25519 or X25519 where
instead it should talk more generally about both the curves
in draft-irtf-cfrg-curves-11. These should be cleared up too.

Cheers,
Brian
-- 
https://briansmith.org/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Thu, Dec 31, 2015 at 09:55:10AM +1100, Martin Thomson wrote:
> On 30 December 2015 at 22:16, Ilari Liusvaara  
> wrote:
> >> Would it make sense to have session hash as a requirement in TLS
> >> 1.2 when you want to use Curve25519?
> >
> > 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.

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

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

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

[Watson Ladd]

On Dec 30, 2015 7:08 PM, "Ilari Liusvaara"  wrote:
>
> On Thu, Dec 31, 2015 at 09:55:10AM +1100, Martin Thomson wrote:
> > On 30 December 2015 at 22:16, Ilari Liusvaara 
wrote:
> > >> Would it make sense to have session hash as a requirement in TLS
> > >> 1.2 when you want to use Curve25519?
> > >
> > > 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.
>
> 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.

Why not hash the public values into the result of the key exchange? I don't
want security to depend on omittable checks.
>
>
> -Ilari
>
> ___
> 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] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

[Eric Rescorla]

On Wed, Dec 30, 2015 at 7:23 PM, Watson Ladd  wrote:

>
> On Dec 30, 2015 7:08 PM, "Ilari Liusvaara" 
> wrote:
> >
> > On Thu, Dec 31, 2015 at 09:55:10AM +1100, Martin Thomson wrote:
> > > On 30 December 2015 at 22:16, Ilari Liusvaara <
> ilariliusva...@welho.com> wrote:
> > > >> Would it make sense to have session hash as a requirement in TLS
> > > >> 1.2 when you want to use Curve25519?
> > > >
> > > > 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.
> >
> > 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.
>
> 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


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

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

[Ilari Liusvaara]

On Wed, Dec 30, 2015 at 07:23:12PM -0500, Watson Ladd wrote:
> On Dec 30, 2015 7:08 PM, "Ilari Liusvaara"  wrote:
> >
> > 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.
> 
> Why not hash the public values into the result of the key exchange? I don't
> want security to depend on omittable checks.

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


-Ilari

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

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

[Brian Smith]

Watson Ladd  wrote:

> Why not hash the public values into the result of the key exchange? I
> 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/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

On 30 December 2015 at 22:16, Ilari Liusvaara  wrote:
>> Would it make sense to have session hash as a requirement in TLS
>> 1.2 when you want to use Curve25519?
>
> 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.

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

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

[Alyssa Rowan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

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

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

(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
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJWhMnAAAoJEOyEjtkWi2t6wZsQAJk767t5ZE28uDYsSCT1fS9u
z6szG2xGnq6jc4T40AZEWeabs9j0n15MZHvFkxQwmtF00dUspIrcRzpct8hXkx0K
q83rotDKGIiCU9K9a6E4Xas/cxxQ8LDTtB937PsyOIpzPOe/fXHu+KTIgtrLL7Cb
OefYyGf7ymRVm0UP9IrIkK99enu0HPuMjqcDdKfW9JVAvb+jgfTyO+qDipYtH8s0
jo3HhCsMiCJlxFaI32viREW/Jcwu4cyttjCvgOPCQUmJ3TQdAC1ucWXpNHgRp07y
RY3+TJfNx9tmmgOoXvGox67hoKKvFaSO8ckqhXrG/V46xLP2FNDEEsaGd0cuKeEb
7T+/0ae9/mzQm3PYhpufU+FiroTDUuYKvjTHfzEY7xPjjpeQT/OdqyrEseJqFfCC
sCKQQPx40vg1dwU6pJ7KyCEJ14RVY5rXmhvkKjGnfI5tziykKibMnqF1MbPh/BK/
L35fQyeJVb6rAaL8iPJx/ilvdJDESAgWic/UooywWkU8HrH6FAXiIV6i1BmkscXn
e3yQB55SVYHv+yPfcNJAyZDXYVln6EoFwVU3rjYxcnAib2z52m2HOyh7NjrBpvVx
8CuIxU+FytE8BUrkayciOS2AFvGUIsf0c/eogDX9A10U6pOoFCRigLRYKFgRbJ3l
M19UbePdsDBYgnd5sEel
=CRt3
-END PGP SIGNATURE-

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

Re: [TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit.

[Kurt Roeckx]

On Tue, Dec 29, 2015 at 09:02:25AM -1000, Brian Smith wrote:
> 
> Does that matter, though? The CFRG document doesn't allow the sender to set
> the high bit to 1, right? In particular, it says "All calculations are
> performed in GF(p), i.e., they are performed modulo p." and "For X25519,
> the unused, most-significant bit MUST be zero."
> 
> If the receiver can detect that the sender is non-conforming, then it
> should be able to stop talking to it on that basis alone.

I don't know enough about all the various draft to know if this
might be a problem or not, but I'm concerned about providing an
error oracle.


Kurt

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