IETF Logo Mail Archive

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

Christian Huitema <huitema@huitema.net> Tue, 23 May 2017 16:53 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 42F29129BB6 for <tls@ietfa.amsl.com>; Tue, 23 May 2017 09:53:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level:
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 8tDsfvnWEEtU for <tls@ietfa.amsl.com>; Tue, 23 May 2017 09:53:15 -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 30449129BB7 for <tls@ietf.org>; Tue, 23 May 2017 09:53:13 -0700 (PDT)
Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx43.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1dDD3V-00083U-Gz for tls@ietf.org; Tue, 23 May 2017 18:53:11 +0200
Received: from internal.xmail09.myhosting.com ([10.5.2.31] helo=xmail09.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <huitema@huitema.net>) id 1dDD3O-0003xQ-Of for tls@ietf.org; Tue, 23 May 2017 12:53:06 -0400
Received: (qmail 17296 invoked from network); 23 May 2017 16:53:00 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.98]) (envelope-sender <huitema@huitema.net>) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 23 May 2017 16:52:59 -0000
To: tls@ietf.org
References: <CAAF6GDcKZj9F-eKAeVj0Uw4aX_EgQ4DuJczL4=fsaFyG9Yjcgw@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> <f8f8db4a-7d4e-590b-25c2-b1cbac6b5313@huitema.net> <CAAF6GDcarzUXiEAxBm9RaLQT5A3B=2TPkngEavEY=wQMHU=9Gw@mail.gmail.com> <1c188f36-c197-20f7-48e4-5d75ac4a2211@akamai.com> <CAAF6GDfCRD3nQmr0JB75CxLkqjmDiWn9co0DXCJHwS3TK625WA@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <55096b5d-dc74-fae4-57e3-83d4355d6050@huitema.net>
Date: Tue, 23 May 2017 09:52:57 -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: <CAAF6GDfCRD3nQmr0JB75CxLkqjmDiWn9co0DXCJHwS3TK625WA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------959FFB88B12028CAC953A15E"
X-Originating-IP: 168.144.250.177
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.10)
X-Recommended-Action: accept
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49L/N1imVzxQGuMdyq1ILpVFTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXrx020Zi//u8HtKCQmu2avRRcOb18WfxGyg6Om6u4YYmz3HWtx6ULqZPKO4 CxOGNv05hjoyEb9Oq0NWpyO3vrfYNrJwCbVSZviV1vzVlxiUlT3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBe34TY+s3lj/RgDQoaICKQ3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0ma9ESR2T lyxgm/asCsGmwrbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgD5 8bDUIriOSOQTK7vaz2jBsjp0rjSY76LAIHA6cW4Oaw3SZdCEEykPbW5B2y73KchnOoRs9Tq8+LVB +WakvuJMxdwDV/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/YyPJndEfpqu_geg8eg9ajL385Rk>
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: Tue, 23 May 2017 16:53:17 -0000


On 5/22/2017 7:53 PM, Colm MacCárthaigh wrote:
>
>
> On Mon, May 22, 2017 at 7:23 PM, Benjamin Kaduk <bkaduk@akamai.com
> <mailto:bkaduk@akamai.com>> wrote:
>
>
>     Sorry for being daft, but a direct link to this additional
>     side-channel would be helpful.
>
>
> I should have done it the first time.  Here it
> is: https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01277.html
>

Colm's point is that for many DNS servers, queries are not truly
stateless. The answer to a query for AAAA records for example.net might
vary over time, or even query to query, for example to manage load
balancing. Adversaries can predict these variations. They can observe
the state of the server before and after replaying 0-RTT data. If they
observed that the 0-RTT data caused the answer to change, they can
confirm that the 0-RTT data contained a request to that server.

I take that as an example of the more generic statement, that it is
really difficult to guarantee that transactions are really stateless.
Some transactions are apparently stateless, because the operation in
theory only reads data from the server. But even these transactions can
change the state of the server in subtle ways, such as servers managing
load balancing. Another example would be web servers rotating
advertisements on the page, which also can be observed. If I get Colm's
point correctly, he asserts that this is a fairly general pattern, and
that only fools can assume that a given transaction is "stateless".

I take that as a strong argument for requiring "at most once"
functionality for 0-RTT data.

-- Christian Huitema

v2.23.0 | Report a Bug | By Email