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

Phillip Hallam-Baker <hallam@gmail.com> Sun, 17 November 2013 03:21 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB8F11E83C3 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 19:21:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level:
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wq0jeiuiS-1 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 19:21:21 -0800 (PST)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id D2B9411E83CD for <tls@ietf.org>; Sat, 16 Nov 2013 19:21:20 -0800 (PST)
Received: by mail-la0-f53.google.com with SMTP id ea20so3856912lab.40 for <tls@ietf.org>; Sat, 16 Nov 2013 19:21:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qAdoIB4AOmfrL7Xr4lS7nfZ5IMFI/W3x+DQz1qI4Ifs=; b=itdZS+RVeADEqw8TczkvYTW3VIyMcVID9y9YRS7bktnV+q43WT42JxR4/pZjfm5n04 5EUAh2K/GZsEKdX9GoR+6f4gHsTpbSyAkKS0Y2nZ9Ffsui5eOYIEMVBnGMv4qX2QakJ9 T2xivWHfzZW9xC00VU4Yjby55zHQgMjzybIJYQ0M7TxKrT2guiizaRXstmhohDfMf4PT MDJC4a6txOey8ZEnUYyWmJaAhVSbfLC813r6+1C1KzVgB6hAhqbhoLHtKdrtkDv6oOB8 Snkh6N1mss/280XpuSuI8VrijebqU2+pN5jXMGBBOcrok7aPok8djjt3wqKHBLfEgGeI 7Jmg==
MIME-Version: 1.0
X-Received: by 10.112.168.170 with SMTP id zx10mr8134494lbb.0.1384658479780; Sat, 16 Nov 2013 19:21:19 -0800 (PST)
Received: by 10.112.46.98 with HTTP; Sat, 16 Nov 2013 19:21:19 -0800 (PST)
In-Reply-To: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com>
References: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com>
Date: Sat, 16 Nov 2013 22:21:19 -0500
Message-ID: <CAMm+LwgJv-NBbPskpjSS4TV-KEFhfu=0RATu=i6b6-kN+J_AiQ@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="001a11c23c88d298ec04eb56ece5"
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.12
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: Sun, 17 Nov 2013 03:21:22 -0000

I am OK with this provided that we also make a Kerberos ticket like fast
session set up mandatory to support. This need not be the existing scheme
since we are talking about rejigging the key negotiation.

I certainly like the idea that TLS 1.3 becomes synonymous with the gold
standard for security. Knocking out the weak ciphers, key lengths and key
negotiation mechanisms is a good way to slim down the protocol.

But maybe one change we should consider is to break apart the cipher suites
so that we don't need to spend so much time discussing them.

If we made the cipher suite ID longer then we could break them down into
fields. The first few bits could specify whether the field zones are 8, 12
or 16 bits and then allocate numbers to each cipher.

The client and server would still negotiate over specific cipher suites but
adding a new block cipher would be one registry addition not twenty.



On Sat, Nov 16, 2013 at 7:47 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> One of the topics we didn't really get to in Vancouver was the fate of
> the static RSA ciphersuites. We'll eventually need to decide on this
> for TLS 1.3.
>
> Note that this isn't a question of either of the following:
>
> * Removal of RSA from TLS 1.2 and below. There are still plenty of
>   clients which only do static RSA and we can't actually break them
>   for a long time.
>
> * Removal of the use of RSA certificates: we would still almost
>   certainly need ephemeral cipher suites where the server uses their
>   RSA key for authentication, just like in the current RSA_DHE and
>   RSA_ECDHE cipher suites.
>
> The question is only for TLS 1.3 and only for static RSA.
> (If you think differently, please raise on another thread.)
>
>
>  This message tries to summarize what I take to be the main arguments
> for and against.
>
> Static RSA has obvious deficiencies:
>
> - It doesn't offer forward security.
> - The larger key lengths that are required for security are increasingly
>    uncompetitive with other algorithms (principally EC).
>
> Additionally, since we know we want to offer ephemeral key agreement
> modes such as DHE (see the recommendations in
> http://tools.ietf.org/html/draft-sheffer-tls-bcp-01) it would reduce
> complexity to *only* offer such modes rather than having to support
> static RSA as well.
>
> This isn't a no-brainer, though. Static RSA is still by far the
> dominant key exchange algorithm and if you have an RSA certificate, is
> strictly faster than any ephemeral suite. So, we're asking everyone to
> take a performance hit at the same time as we're trying to make TLS
> faster; of course this is a computational cost rather than one of
> network latency, but there are still applications where that matters,
> especially in constrained devices.
>
> There are also some settings where PFS is actually undesirable,
> especially for diagnosis and monitoring. In this settings, it's much
> more convenient to simply provide the monitoring device with the
> server key. ssldump and wireshark, for instance, both provide this
> feature.
>
> Please use this thread to discuss.
>
> -Ekr
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>


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