Re: [TLS] cross-domain cache sharing and 0rtt

Benjamin Kaduk <bkaduk@akamai.com> Wed, 04 January 2017 00:14 UTC

Return-Path: <bkaduk@akamai.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 1E23E1294ED for <tls@ietfa.amsl.com>; Tue, 3 Jan 2017 16:14:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.8
X-Spam-Level:
X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
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 s2RfztsAOzW2 for <tls@ietfa.amsl.com>; Tue, 3 Jan 2017 16:14:25 -0800 (PST)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0861294FA for <tls@ietf.org>; Tue, 3 Jan 2017 16:14:25 -0800 (PST)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7B9CA433433; Wed, 4 Jan 2017 00:14:24 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 5B05E433431; Wed, 4 Jan 2017 00:14:24 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1483488864; bh=A3i5bkbex8L1hLCHorz2BkSXzWK6XqQCMf1tZQ7dd84=; l=3741; h=To:References:Cc:From:Date:In-Reply-To:From; b=lFsLOdW3aqenlov5PasRetqxUhfZFouqqxzmfm1+XQ+WT70TfGWuho3McctvZK6Qd GVglIoTcuOjZ/LGhg9w22NGxd2OkyvwhuZ9P7QPB9h9blNxkp3nhM1TqCoHRJ4yIu+ lRwN8ZhxttgOqEDhmcUqUFKEGbOz7lPRfVEHe2YQ=
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 1A5E61FC88; Wed, 4 Jan 2017 00:14:24 +0000 (GMT)
To: Ilari Liusvaara <ilariliusvaara@welho.com>, Adam Langley <agl@imperialviolet.org>
References: <CAMfhd9Urd1DWF9yhMdhvx1AcKyB4-E7Qy+tzqz_-1RpXR+Wp1w@mail.gmail.com> <79db4a88-e435-2e5b-47a5-9048acef45e2@cs.tcd.ie> <CABcZeBObcWUjdHhysLG1K0TbJfiqN+XCERn6WaMjWzgU0XC65A@mail.gmail.com> <582703ab-4340-35e7-a3d2-45dd606f10a1@cs.tcd.ie> <CABcZeBMx3zJ07pbj0bPBMrAcrK_Q4HVDcbCx_2B1DnyCOJeE-g@mail.gmail.com> <CAMfhd9Xt400wyOqvREWMXPL2_gsAJsZRqmRAFLq9tKzOKuqnjA@mail.gmail.com> <20161230124420.GA11229@LK-Perkele-V2.elisa-laajakaista.fi>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <5e06f30a-2f29-0c1f-432b-ed02c7f6c5ae@akamai.com>
Date: Tue, 03 Jan 2017 18:14:23 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <20161230124420.GA11229@LK-Perkele-V2.elisa-laajakaista.fi>
Content-Type: multipart/alternative; boundary="------------36D410612ACEC6681271E492"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/BhcB8pNtGLHrNLnoBNE0IIceJmE>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] cross-domain cache sharing and 0rtt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 04 Jan 2017 00:14:27 -0000

On 12/30/2016 06:44 AM, Ilari Liusvaara wrote:
> On Thu, Dec 29, 2016 at 02:45:53PM -0800, Adam Langley wrote:
>>
>> An attacker could redirect a 0-RTT handshake that was destined to S1
>> and feed it to S2. If S2 ignores the SNI value (common) it could
>> accept and process the 0-RTT data even though it was destined for S1.
> Sounds like standard-issue default-vhost attack (which are sadly
> common security issues in https://).
>  

Somehow, I feel like adding text in the 1.3 spec that servers should not
do this is not really going to help anyone.

>> However, in that case TLS 1.2 is probably also affected because S2
>> would likely process a 1.2 handshake that was destined to S1 as well.
>> (Even without a shared ticket key or session cache.) See
>> http://antoine.delignat-lavaud.fr/doc/www15.pdf for more.
> You mean redirecting full handshake meant for s1.example.com to
> s2.example.com? Or redirecting a TLS 1.2 resumption handshake?

Naively, if s1 and s2 share cert and private key, and ignore the SNI, it
seems like redirecting a full handshake would work.  But I didn't think
about it very hard.

> Also, wonder how many servers don't check for SNI when resuming...
>


Me, too.

-Ben