Subject: [Cfrg] PKI versus confidentiality Re: Elliptic Curves - poll on security levels (ends on February 17th)

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Feb 2015 11:41:21 -0500

On Tue, Feb 10, 2015 at 10:31 AM, Dan Brown <[email-masked]> wrote:

> > From: Phillip Hallam-Baker
> > Sent: Tuesday, February 10, 2015 10:14 AM
>
> > The two places we will be using the code is for ephemeral key agreement
> and
> > for initial agreement of a
> > master key. Assuming that we fix the TLS key derivation alg so that a 128
> > bit ephemeral does not weaken a
> > 256 bit negotiation, I predict ephemeral will be exclusively Curve 25519
> and
> > PKI will be exclusively
> > Curve~512.
>
> Counterarguments for the opposite, i.e. 128-bit security for PKI and
> 256-bit
> security for key agreement. First, confidentiality often relies key
> agreement
> and confidentiality potentially needs long-term (future) security, so
> margin-of-error is arguably more important. PKI, by definition, is only as
> secure as the security of CAs and the security of the communication used to
> obtain their CA self-signed certificates: larger key sizes does not fix
> these
> two bottlenecks.
>

Well first off, I note that even though you are disagreeing with my
examples, you are using the same two security levels.

Secondly, the argument can always be made that crypto is going to be
stronger than any other link in the chain. The chance of a compromised
endpoint is much higher than the chance of someone breaking your crypto.
But the difference is that crypto algorithms only ever get worse over time.
Other points of vulnerability can get better.

Don't rail against PKI in general just because you don't like the WebPKI.
If you don't trust someone else to run your network PKI then take control
of it yourself. TLS is not just an inter-network security protocol, it is a
network security protocol as well.

PKI is theoretically the weakest link in the chain but in practice we have
had far more failures in every other part. We have had far more certs
cracked due to weak algorithms (MD5) than misissue. (People who don't kill
support for MD2 and MD4 in their protocol libraries completely will be in
for a world of hurt soon.)

There are two cases in which I really care about the algorithm strength,
they are authentication and long term stored data encryption.

I can see real value in a fast curve for perfect forward secrecy in TLS.
Ideally, I would want to see the key exchange redesigned that using a 128
bit strength ephemeral key does not weaken the security of a 256 bit
strength PKI key.

For S/MIME, I can't see any point in speed at all. Just go with 128 bit
only. Its store and forward and it is the one case where we would like to
increase the cost to bulk senders. Using a 128 bit strength key makes sense
for DKIM though.