Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,

From: Nigel Smart <[email-masked]>
Date: Mon, 30 Jun 2014 20:16:12 +0100

> Nobody's asking the IETF, little more than a collection of mailing lists, to take liability should 25519 be cracked or have a back door.

What's the difference between defining a cryptographic protocol (i.e. 
TLS 1.3)
which could have lots of problems/be cracked/have a back door; and defining
a cryptographic algorithm which could have lots of problems/be cracked/have
a back door? Experience shows us that defining cryptographic protocols
(key agreement/secure channels) is more prone to problems than defining
cryptographic primtives (AES, ECC).

If IETF is just a collection of mailing lists, and no one takes 
responsibility
for the security implications of the security bits in it, then what is 
the point
of TLS 1.3?
    - But then again the collection of mailing lists is what resulted in 
TLS 1.2
      So in some sense TLS 1.3 is to correct the output of a collection 
of mailing
      lists which produced TLS 1.2               :-)

My personal opinion is that the IETF should use
    i) Externally validated cryptographic primitives (i.e. AES, SHA-3, 
specific ECC
       choices etc).
   ii) Externally validated cryptographic protocols (i.e. throw out most of
       existing TLS methodology). Finding external validation of 
protocols is
       however currently a problem. Since TLS 1.3 is meant to offer a 
key agreement
       protocol and a secure channel protocol; and there are very few 
standards
       for such things.

Now 25519 is both. It is a cryptographic primitives (a specific elliptic 
curve)
AND an associated protocol (the specific form of key agreement protocol
which uses the said curve).  Given neither have any form of external 
validation
I do not think IETF should use them.

Nigel

---

From: Michael StJohns <[email-masked]>
Date: Mon, 30 Jun 2014 17:20:29 -0400

> cryptographic primtives (AES, ECC). 

If the math is insecure then the cryptographic standard is insecure as 
is everything that depends on it.

If the cryptographic standard is insecure then the cryptographic 
protocols are insecure (but hopefully you can plug in something else - 
e.g. DES vs AES).

If the cryptographic protocol is insecure then the applications are 
insecure (but hopefully you can plug in something else e.g.  TLS1.0 vs 
TLS1.1 vs TLS1.2 vs ??).

Oh yeah - if the implementation is insecure, it doesn't really matter 
whether or not you got everything else right.

So the difference is really about what depends on the protocol vs the 
standard vs the math, and you get more dependencies the closer you are 
to the math.

I tend to agree with you about the problems with defining crypto 
protocols, but at least they are*protocols* which is somewhat within the 
IETF's scope of expertise.  They're also a lot easier for the 
non-crypto-math people to get their heads around.  Crafting a 
cryptographic protocol is still a specialty expertise though.  At least 
TLS13 will have *lots* of eyes on it.  Given the huge set of plugin 
cryptography in TLS, hopefully at least some of it will be secure enough.

Mike

---

From: Watson Ladd <[email-masked]>
Date: Mon, 30 Jun 2014 15:21:32 -0700

TLS 1.3)
> If the math is insecure then the cryptographic standard is insecure as is
everything that depends on it.
> If the cryptographic standard is insecure then the cryptographic
protocols are insecure (but hopefully you can plug in something else - e.g.
DES vs AES).
> So the difference is really about what depends on the protocol vs the
standard vs the math, and you get more dependencies the closer you are to
the math.
protocols, but at least they are*protocols* which is somewhat within the
IETF's scope of expertise.  They're also a lot easier for the
non-crypto-math people to get their heads around.

Not really: TLS 1.0 had an obvious flaw, BEAST. Kerberos went through 5
versions, each one broken before the next. However easily it looks to
understand,  you didn't find Triple Handshake. Did you really understand
TLS, or just think you did?

Crafting a cryptographic protocol is still a specialty expertise though.
 At least TLS13 will have *lots* of eyes on it.  Given the huge set of
plugin cryptography in TLS, hopefully at least some of it will be secure
enough.

Any improvement won't come from lots of eyes. It will come from a few
cryptographers sitting down and ripping stuff to shreds.

Plugin cryptography hasn't made it easy to kill RC4.
Sincerely,
Watson Ladd
>
> Mike
>
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls