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

Andy Lutomirski <luto@amacapital.net> Tue, 19 November 2013 02:54 UTC

Return-Path: <luto@amacapital.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3F51AEB18 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 18:54:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wn0Ep6RobYDB for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 18:53:59 -0800 (PST)
Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id C4A9A1AEB0B for <tls@ietf.org>; Mon, 18 Nov 2013 18:53:59 -0800 (PST)
Received: by mail-pa0-f43.google.com with SMTP id fa1so7674201pad.30 for <tls@ietf.org>; Mon, 18 Nov 2013 18:53:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WCQCgchSkfFrUfAavfKEbJnMgF+zrk+0uB8RZTVwWMQ=; b=LMqrnTxp4c3sJzCdcuQOpJiQvKCj8QcggZ6SJtwpzYMtgBVgxfjP73lCS2Q9mJrz5+ EnjgDv6zHBSSy92iGzuJ8KZNoRC/5SnKxOEJtuM+AFRWnY8NC+5cSvpCBCrks9xsBfiI 30hgv0+DO1R0Jqa6d7FwSTDZO6JRvs04x6CwkdWSVi2M9n7Y7IP4IMrVa6fbSbJTmjRD j/hjKQCbhZ2t0XBoFnD1TgsBvzsm2MuFAjmGakrxm2i1cpTAWeCTvpznr4+vHZBMtJmV uGeGjve2gi2t6JbUxof6p7K5hSciZcsWK/KvxkaWXCBTL/5EvHo0ohw2t+kadnQyCPEF TVMQ==
X-Gm-Message-State: ALoCoQkOgP0DtYs9ovBmI4UgWebPKo1k18AoQjYcpb9Z+Sg0Zm8Ho3G2d/QQAj7uL/gZDWWnPLrg
X-Received: by 10.66.197.164 with SMTP id iv4mr20175821pac.18.1384829633895; Mon, 18 Nov 2013 18:53:53 -0800 (PST)
Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id tu6sm26700328pbc.41.2013.11.18.18.53.52 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Nov 2013 18:53:53 -0800 (PST)
Message-ID: <528AD2BF.8070304@amacapital.net>
Date: Mon, 18 Nov 2013 18:53:51 -0800
From: Andy Lutomirski <luto@amacapital.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Eric Rescorla <ekr@rtfm.com>, Geoffrey Keating <geoffk@geoffk.org>
References: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com> <m238mv1wkq.fsf@localhost.localdomain> <CABcZeBPzYi3rztRv7-mNWf7BwTJ83-Sc1c_=j4kN8nJhh2FCjA@mail.gmail.com>
In-Reply-To: <CABcZeBPzYi3rztRv7-mNWf7BwTJ83-Sc1c_=j4kN8nJhh2FCjA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Should we support static RSA in TLS 1.3?
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Nov 2013 02:54:03 -0000

On 11/16/2013 09:29 PM, Eric Rescorla wrote:
> On Sat, Nov 16, 2013 at 8:28 PM, Geoffrey Keating <geoffk@geoffk.org
> <mailto:geoffk@geoffk.org>> 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.
> 

Except that TLS 1.3 at least doesn't really make this possible with the
way that PKIX works now.  This could be changed.

(For what it's worth, static RSA is faster on the client side than
short-term fixed DH certificates, but fixed DH may result in a cleaner
protocol.  I suspect that fixed ECDH is quite a bit faster than either.)

--Andy

> -Ekr
> 
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>