IETF Logo Mail Archive

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

Christian Huitema <huitema@huitema.net> Mon, 22 May 2017 17:47 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 B767912009C for <tls@ietfa.amsl.com>; Mon, 22 May 2017 10:47:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8KAmBVy8mjAu for <tls@ietfa.amsl.com>; Mon, 22 May 2017 10:47:00 -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 67790124E15 for <tls@ietf.org>; Mon, 22 May 2017 10:47:00 -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 1dCrQ0-00083U-6S for tls@ietf.org; Mon, 22 May 2017 19:46:58 +0200
Received: from [10.5.2.35] (helo=xmail10.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 1dCrPu-0002Kr-4b for tls@ietf.org; Mon, 22 May 2017 13:46:54 -0400
Received: (qmail 21263 invoked from network); 22 May 2017 17:46:48 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.98]) (envelope-sender <huitema@huitema.net>) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 22 May 2017 17:46:47 -0000
To: Colm MacCárthaigh <colm@allcosts.net>, Kyle Nekritz <knekritz@fb.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> <MWHPR15MB1182F59E2B60534CB20EC9C4AFF80@MWHPR15MB1182.namprd15.prod.outlook.com> <CAAF6GDeNWpKM_Uu5zN70gW9L=WSLZVJhi=OZwYOC3y24zuphpQ@mail.gmail.com>
Cc: "tls@ietf.org" <tls@ietf.org>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <f8f8db4a-7d4e-590b-25c2-b1cbac6b5313@huitema.net>
Date: Mon, 22 May 2017 10:46:43 -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: <CAAF6GDeNWpKM_Uu5zN70gW9L=WSLZVJhi=OZwYOC3y24zuphpQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------0956D0D9515423A36D630600"
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.12)
X-Recommended-Action: accept
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49LCP7NcwZmTrFhTWonoFoqtTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXoWIPlnrfEDRiyWf+KtRxCHRcOb18WfxGyg6Om6u4YYm9aWSU9YfXahEmwF qtDcd2Y5hjoyEb9Oq0NWpyO3vrfYoocEfHwV+0ePfQGXOSgIJz3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB9a2LHJVD1n7GG0fP4s+aInTFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0dzvzp+mG 5Y/zCY7DUzpfU7bRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgD5 8bDUIriOSOQTK7vaz2jBsjp0rjSY76LAIHA6cW4Oa0NgfQDX7DQ+bDeh72B3Mio8arn2PuuzhjWm yAwjA2zXxdwDV/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/IJSas_C8YLfOKdOujq6uRs_YaM4>
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 17:47:03 -0000


On 5/22/2017 10:24 AM, Colm MacCárthaigh wrote:
>
>
> On Mon, May 22, 2017 at 10:12 AM, Kyle Nekritz <knekritz@fb.com
> <mailto:knekritz@fb.com>> wrote:
> ...
>
>     Which mechanisms to use, and whether to enable 0-RTT in the first
>     place (or PSK mode at all), should be decided considering the
>     tradeoff between security/performance/implementation constraints,
>     etc. In the case of DNS, most DNS security protocols (dnssec,
>     etc.) do allow this kind of replay so I think it is a pretty
>     reasonable tradeoff to consider.
>
>
>
> This same argument could be made for keeping MD5, or RC4.  DNSSEC is
> not concerned with secrecy. TLS is. This exact kind of replay would
> compromise the secrecy of the data being transported. 
>  
Check DKG's analysis of 0-RTT for DNS over TLS:
https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01276.html.
There is only one point of concern, a minor privacy leak if the DNS
queries in the 0-RTT data can be replayed at intervals chosen by the
attacker. The idea is to replay the data to a resolver, and then observe
the queries going out to authoritative servers in clear text. The
correlation can be used to find out what domain the client was
attempting to resolve. The attack requires "chosen time" by the
attacker, and thus will probably be mitigated by a caching system that
prevents replays after a short interval.

-- Christian Huitema

v2.23.0 | Report a Bug | By Email