IETF Logo Mail Archive

Re: [TLS] Security review of TLS1.3 0-RTT

Christian Huitema <huitema@huitema.net> Mon, 22 May 2017 05:26 UTC

Return-Path: <huitema@huitema.net>
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 F33C9129B30 for <tls@ietfa.amsl.com>; Sun, 21 May 2017 22:26:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.101
X-Spam-Level:
X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 VnNgMR5ONSkJ for <tls@ietfa.amsl.com>; Sun, 21 May 2017 22:26:21 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DC31129B3C for <tls@ietf.org>; Sun, 21 May 2017 22:26:19 -0700 (PDT)
Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1dCfrF-0004UR-1R for tls@ietf.org; Mon, 22 May 2017 07:26:17 +0200
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1dCfr9-0003Ng-C5 for tls@ietf.org; Mon, 22 May 2017 01:26:15 -0400
Received: (qmail 27739 invoked from network); 22 May 2017 05:26:09 -0000
Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.56.42.111]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 22 May 2017 05:26:07 -0000
To: Colm MacCárthaigh <colm@allcosts.net>, Eric Rescorla <ekr@rtfm.com>
References: <CAAF6GDcKZj9F-eKAeVj0Uw4aX_EgQ4DuJczL4=fsaFyG9Yjcgw@mail.gmail.com> <CABcZeBNcnW9zEPZ4mEje1_ejR3npNFz65rw-6qUPn7cQt1Nz9w@mail.gmail.com> <CAAF6GDe1_ih1aUShrzAHUuTzbLx6+0BdVexpGnq90RZsST8GvA@mail.gmail.com> <CABcZeBOX5NXuhgfap2S0naO9PFXv+K-+fZVPbgck6yciVnrYbQ@mail.gmail.com> <CABcZeBPuOupLTNKOtuCgOjYNdiuw571HM-pq1vNZz_8x-XX5mg@mail.gmail.com> <CABcZeBMqALJ10cU7FMUhv8k5Q=tw3yu1-5pdrKzOBM3=g5PHJw@mail.gmail.com> <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi> <CAAF6GDeuRMZx9MRynrxMp1fCvRS2jjr0vcqt0R89cJEkD6u=rQ@mail.gmail.com> <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBNj_X4qbXrH4732kQiAHrBpPZhW1nmn4Xnp-pm0gv1Psg@mail.gmail.com> <CAAF6GDcEKaBaJZU0q822KqoJDL5kyZJGbOBKsnU9tnpU=YvoxA@mail.gmail.com>
Cc: "tls@ietf.org" <tls@ietf.org>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <d5ad3bf1-d05a-4e27-2ea9-f7c60b4b0c18@huitema.net>
Date: Sun, 21 May 2017 22:26:04 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAAF6GDcEKaBaJZU0q822KqoJDL5kyZJGbOBKsnU9tnpU=YvoxA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------3E06E92CC622CDB4A6B9E27A"
X-Originating-IP: 168.144.250.230
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.14)
X-Recommended-Action: accept
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49LCP7NcwZmTrFhTWonoFoqtTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXpynqmxH7KpPKZAVjX1Se8CRcOb18WfxGyg6Om6u4YYm9YArbdtautoyLzS s/JWDXc5hjoyEb9Oq0NWpyO3vrfYoocEfHwV+0ePfQGXOSgIJz3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB9a2LHJVD1n7GG0fP4s+aInTFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0AdUEPptZ 3fLBarnabQfPf7bRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgD5 8bDUIriOSOQTK7vaz2jBsjp0rjSY76LAIHA6cW4Oa0k1QmJ32eA5/D47ikwJamSKsuHVheBSoveD wM1QT+afxdwDV/LdQk4Dnvnv/o4ZpIN8Tfe43vaXKX/yihCEqxIlRZaHuAWSnHeK3PdSA6Q+2n/k rhIYlNMbfS0wdTtG+6JGvz6FazW2uq9LM3++XT4UhuDAoR32cV4eNY9hrm4n
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/F1_8t-1wb7pMROxGwmmHrAkC5_0>
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 22 May 2017 05:26:23 -0000


On 5/21/2017 7:28 PM, Colm MacCárthaigh wrote:
>
>
> On Sun, May 21, 2017 at 3:47 PM, Eric Rescorla <ekr@rtfm.com
> <mailto:ekr@rtfm.com>> wrote:
>
>
>
>     ...
>
>     I'm happy to write this up as part of the first two techniques.
>     I'd be 
>     interested in hearing from others in the WG what they think about:
>
>     1. Requiring it.
>     2. Whether they still want to retain the stateless technique.
>
>
> I'm for requiring it, and for removing the stateless technique ...
> because it prevents the side-channel and DOS attacks and those seem
> like the most serious ones (and also, the new ones). 
>
> So far each case where we've thought "Actually stateless might be ok
> in this case" ... like the example of DNS ... turns out not to be safe
> when examined more closely (in DNSes case it would compromise privacy
> because caches could be probed). 

I would much rather see this specified within TLS than within the
application. Specifically, I would not like to see application making
statements that they can only use 0-RTT if the TLS software that they
use does implement "at most once" limitations on 0-RTT tickets. You
know, pretty much like those security sections that explain than a
careless application will be safe if it runs over IPSEC. Maybe with some
RFC 6919 language.

-- Christian Huitema

v2.23.0 | Report a Bug | By Email