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

Phillip Hallam-Baker <> Tue, 19 November 2013 14:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4EB6F1ADFE7 for <>; Tue, 19 Nov 2013 06:58:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 35SNLDp4Gsqx for <>; Tue, 19 Nov 2013 06:58:33 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::236]) by (Postfix) with ESMTP id AC51A1ADFF9 for <>; Tue, 19 Nov 2013 06:58:32 -0800 (PST)
Received: by with SMTP id u14so2780198lbd.27 for <>; Tue, 19 Nov 2013 06:58:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0aiDHouCwXQi7i0GYH5Ezelz/Cz5cDoHor90YEPnJvY=; b=DWv4Fc4wblkFc8fMsdP5oO+kbRXtsq/kr1MIpUTgLGCqjpUP9Xn8dBTlbS2l8s8RbY DxRg28s3pIOIvHaJqBpsdse3loTO4WJgz0zm6YvVsjQ1/D4juUg8z5L7dhZWAabU8cen 5Eoq3appWKG/afcR3NDPt1fQaFAS9CZK7B059+4sFGZ5cQDctwgJcoHzYU50mDReINJe kVF/FMKgmpxSZ1UcpCUOHF/zzn1IJojkJ6JxZupxP8WpFqfe80g8rrASrqyFNp5+ZdyR BjuLOlBeDzBuvOPKzAc1IjXrm0YUGlXefCe6euAWl7lFB+YF1GJCaJlVtwTEWi1egJIC 0vSQ==
MIME-Version: 1.0
X-Received: by with SMTP id qb3mr18037523lbb.14.1384873105923; Tue, 19 Nov 2013 06:58:25 -0800 (PST)
Received: by with HTTP; Tue, 19 Nov 2013 06:58:25 -0800 (PST)
In-Reply-To: <>
References: <> <m238mv1wkq.fsf@localhost.localdomain> <>
Date: Tue, 19 Nov 2013 09:58:25 -0500
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Eric Rescorla <>
Content-Type: multipart/alternative; boundary=089e0112c73c89a43b04eb88e528
Cc: Geoffrey Keating <>, "" <>
Subject: Re: [TLS] Should we support static RSA in TLS 1.3?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Nov 2013 14:58:35 -0000

On Sun, Nov 17, 2013 at 12:29 AM, Eric Rescorla <> wrote:

> On Sat, Nov 16, 2013 at 8:28 PM, Geoffrey Keating <>wrote;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

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.