[147305] in cryptography@c2.net mail archive
Re: [Cryptography] forward-secrecy >=2048-bit in legacy
daemon@ATHENA.MIT.EDU (Peter Fairbrother)
Thu Sep 26 06:05:35 2013
X-Original-To: cryptography@metzdowd.com
Date: Thu, 26 Sep 2013 00:37:18 +0100
From: Peter Fairbrother <zenadsl6186@zen.co.uk>
To: Adam Back <adam@cypherspace.org>
In-Reply-To: <20130925122506.GA26838@netbook.cypherspace.org>
Cc: cryptography@metzdowd.com, Crypto List <cryptography@randombit.net>,
Peter Gutmann <pgut001@cs.auckland.ac.nz>, paul.hoffman@vpnc.org,
perry@piermont.com, code@funwithsoftware.org
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On 25/09/13 13:25, Adam Back wrote:
> On Wed, Sep 25, 2013 at 11:59:50PM +1200, Peter Gutmann wrote:
>> Something that can "sign a new RSA-2048 sub-certificate" is called a
>> CA. For
>> a browser, it'll have to be a trusted CA. What I was asking you to
>> explain is
>> how the browsers are going to deal with over half a billion (source:
>> Netcraft
>> web server survey) new CAs in the ecosystem when "websites sign a new
>> RSA-2048
>> sub-certificate".
>
> This is all ugly stuff, and probably < 3072 bit RSA/DH keys should be
> deprecated in any new standard, but for the legacy work-around senario to
> try to improve things while that is happening:
>
> Is there a possibility with RSA-RSA ciphersuite to have a certified RSA
> signing key, but that key is used to sign an RS key negotiation?
>
> At least that was how the export ciphersuites worked (1024+ bit RSA auth,
> 512-bit export-grade key negotation). And that could even be weakly
> forward
> secret in that the 512bit RSA key could be per session. I imagine that
> ciphersuite is widely disabled at this point.
>
> But wasnt there also a step-up certificate that allowed stronger keys if
> the
> right certificate bits were set (for approved export use like banking.)
> Would setting that bit in all certificates allow some legacy
> server/browsers
> to get forward secrecy via large, temporary key negotiation only RSA keys?
> (You have to wonder if the 1024-bit max DH standard and code limits was bit
> of earlier sabotage in itself.)
A couple of points: all the big CAs will give you a new certificate with
a new key for free (but revocation is your baby) - while it isn't
something they do, can't they issue say two years worth of one-day certs
for perhaps a little more than the price of a two-year cert?
In the UK we have a law called RIPA, part of which allows Plod to demand
keys. They can demand keys used for encryption and for key setup - but
they can't demand keys used only for authentication. I don't think they
routinely demand keys from TLS/SSL webservers.
The point is that in an ordinary TLS session the RSA key is used for
both secrecy and authentication - in any future TLS these functions
should be split.
Also, Dan Boneh was talking at this years RSA cryptographers track about
putting some sort of quantum-computer-resistant PK into browsers - maybe
something like that should go into TLS2 as well?
You need to get the browser makers - Apple, Google, Microsoft, Mozilla -
and the webservers - Apache, Microsoft, nginx - together and get them to
agree "we must all implement this" before writing the RFC.
-- Peter Fairbrother
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography