IETF Logo Mail Archive

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

Marsh Ray <maray@microsoft.com> Wed, 20 November 2013 01:50 UTC

Return-Path: <maray@microsoft.com>
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 2B7D11AE2C2 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 17:50:23 -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 RV9VlMf2BI6u for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 17:50:21 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0149.outbound.protection.outlook.com [207.46.163.149]) by ietfa.amsl.com (Postfix) with ESMTP id 451CA1AE2C1 for <tls@ietf.org>; Tue, 19 Nov 2013 17:50:21 -0800 (PST)
Received: from BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) by BY2PR03MB075.namprd03.prod.outlook.com (10.255.241.155) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 20 Nov 2013 01:50:12 +0000
Received: from BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.17]) by BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.139]) with mapi id 15.00.0820.005; Wed, 20 Nov 2013 01:50:06 +0000
From: Marsh Ray <maray@microsoft.com>
To: Eric Rescorla <ekr@rtfm.com>, Watson Ladd <watsonbladd@gmail.com>
Thread-Topic: [TLS] Should we support static RSA in TLS 1.3?
Thread-Index: AQHO4y6wZB7Ttjlkd0Wj6viVfZ6OoZoo1ZKAgAAIrwCAAALFgIAAA8UAgAR4TGA=
Date: Wed, 20 Nov 2013 01:50:05 +0000
Message-ID: <b80b3e7355224fa0aee303d41870fad1@BY2PR03MB074.namprd03.prod.outlook.com>
References: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com> <CACsn0cnd58NwPfmXXdH4NsqPa5Mes2H5_9_HsB+jLJ8ViNG6ig@mail.gmail.com> <CABcZeBMESWo9PN7C-aeAmF+GdOGFxvS45FW=8RK1HqEEk2DPPg@mail.gmail.com> <CACsn0ckcPvm4fBB-7YqQ0HbUNcUbG8dVYL0wquOCTcMneM=JJQ@mail.gmail.com> <CABcZeBMwNh8NnzPD-_68etMWdSJqwsyTp2CDxuijSpkswkUWyw@mail.gmail.com>
In-Reply-To: <CABcZeBMwNh8NnzPD-_68etMWdSJqwsyTp2CDxuijSpkswkUWyw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:ee31::3]
x-forefront-prvs: 0036736630
x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(81816001)(74366001)(56776001)(47446002)(80022001)(79102001)(63696002)(83072001)(77096001)(46102001)(54316002)(76786001)(74316001)(56816003)(76576001)(76796001)(50986001)(76482001)(47976001)(69226001)(31966008)(4396001)(74502001)(47736001)(81686001)(74662001)(74706001)(59766001)(74876001)(81542001)(51856001)(87936001)(2656002)(81342001)(87266001)(33646001)(85306002)(65816001)(77982001)(49866001)(80976001)(83322001)(54356001)(53806001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB075; H:BY2PR03MB074.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ee31::3; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
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: Wed, 20 Nov 2013 01:50:23 -0000

From: Eric Rescorla
> - TLS with False Start is already 1RT, albeit without the client
> being able to verify handshake correctness until he sees the
> server's response.

Might be worth mentioning that False Start on a client was enough
to enable the CRIME attack even if the legitimate server had
compression disabled.

In many ways, common implementations dodged the bullet with
CRIME. But this is an example where aggressive randomized
padding might have saved the day.

Saving every possible half-roundtrip brings huge rewards, and
I'm all for it. But it has its risks too.

- Marsh

v2.23.0 | Report a Bug | By Email