Re: [TLS] Should we support static RSA in TLS 1.3?

[Phillip Hallam-Baker <[e-mail]>]

On Sun, Nov 17, 2013 at 12:29 AM, Eric Rescorla <[e-mail]> wrote:

> On Sat, Nov 16, 2013 at 8:28 PM, Geoffrey Keating <[e-mail]>wrote:
>>
>> Then, if people want a key agreement where one side generates a random
>> master key, encrypts it with RSA, and sends it to the other, we can do
>> that.  The RSA key can be ephemeral (or, at least, changed much more
>> often than today's typical "once every two years"), which gives
>> forward secrecy, or the RSA key can be fixed, if forward secrecy is
>> explicitly not wanted
>>
>
> Oops, yeah, forgot to mention this.
>
> As you say, it's possible to generate a short-term RSA key and use it
> for multiple connections. This gives some level of forward security.
>

Rob Stradling and I were kicking around a scheme that was similar a few
weeks back.

The goal here is not so much forward secrecy as to increase the work factor
for an attacker. We have been considering short lived certs as a mechanism
for addressing the revocation issue for some time. Generating a new cert
with a different key each time does not increase the effort a great deal if
it is thought about at the start.


The precondition for any scheme that involves daily cert issue is that it
be fully automated. And this is the part that needs work. Specifically we
need:

1) Web servers able to switch certificates and keys without a reboot.
2) Automatic generation of key sets and CSRs in advance
3) Automatic issue of certificates.


Note that (2) and (3) are separate because we might well want to use
different tools to do each one. We might even want to do the process in
bulk and generate a whole year's worth of keys at once and the
corresponding CSRs and upload the whole lot to the CA in one go.

It is good to have ephemeral keying AS WELL. But we are currently limited
to only 1024 bits of EK due to the support issues. I would like more.


-- 
Website: http://hallambaker.com/