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

Benjamin Kaduk <bkaduk@akamai.com> Wed, 04 January 2017 21:48 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 68CE7129704 for <tls@ietfa.amsl.com>; Wed, 4 Jan 2017 13:48:28 -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 2fYkJFR2rDKj for <tls@ietfa.amsl.com>; Wed, 4 Jan 2017 13:48:27 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB6E129690 for <tls@ietf.org>; Wed, 4 Jan 2017 13:48:27 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5AD1243341D; Wed, 4 Jan 2017 21:48:26 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 37B2443340E; Wed, 4 Jan 2017 21:48:26 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1483566506; bh=ZmhZqyyGehq2Mg1qmsE68UXrd0oJCpsInHgitKjIi/o=; l=4959; h=To:References:Cc:From:Date:In-Reply-To:From; b=us9U7N+ARFiQ0bhd2e3/2oRW+dn808FxZhoCMJjWJJR3zhuHAPUm10Xs3pfzu7wh7 6W1XMAVJTLD1B9NIDGjqB0YjMyXkQJLQIyNbj8pEq+LT/ISLLc3YyMngu2o0AKVLO8 8438VYpYK5SoKJ27pN1FNl7XWVvyLddQ/FXb+eYo=
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 E0D791FC88; Wed, 4 Jan 2017 21:48:25 +0000 (GMT)
To: Martin Thomson <martin.thomson@gmail.com>, Ilari Liusvaara <ilariliusvaara@welho.com>
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> <5e06f30a-2f29-0c1f-432b-ed02c7f6c5ae@akamai.com> <20170104042901.GA21843@LK-Perkele-V2.elisa-laajakaista.fi> <CABkgnnX8-uMHz=fO5rFcJ=PpT7+nL88uTY7Rz5MBL99+imdYfg@mail.gmail.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <c1e56ee5-cf5e-c0aa-bfc5-c77d4083dc61@akamai.com>
Date: Wed, 04 Jan 2017 15:48:25 -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: <CABkgnnX8-uMHz=fO5rFcJ=PpT7+nL88uTY7Rz5MBL99+imdYfg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------9D3CC68178328FA5191D4BE7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TjGl_pzOOL7F0wCX2QEM2VAznEE>
Cc: Adam Langley <agl@imperialviolet.org>, "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 21:48:28 -0000

On 01/03/2017 10:38 PM, Martin Thomson wrote:
> On 4 January 2017 at 15:29, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
>>> 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.
>> Actually, I think it would work if you merely have cross-valid
>> selected certs. No need to share private key or even ignore SNI.
> That's almost ignoring SNI.  You are X but will accept a connection
> for Y.  It's certainly true that you don't need to share keys, you
> share valid credentials and are willing to use them.
>
> Either way, your point is well made.  How servers identify themselves
> is bound up in how they expect to be identified, which is often
> ambiguous intentionally.
>
> For example, it's common to have a single deployment configuration
> across an entire cluster and to rely on SNI alone for picking a
> certificate.  That way you simplify management and don't have to look
> at IP addresses or anything like that.

It seems like we're violently agreeing with each other, here, and should
settle on text to go (or not go) into the security considerations
section.  In the interest of sparking discussion, I propose the strawman:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

When a server has valid credentials for multiple server names, and at
least one of those names could also be served by valid credentials on a
different server, it may be possible for an attacker
to replay traffic from a client intended for the second server against
the first server, including 0-RTT data.  This behavior can be avoided if
the server knows what server name is expected for a given request (e.g.,
via an HTTP Host header) and verifies that the supplied SNI extension
matches the expected server name, though in some cases the mismatch is
harmless.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Though, to be honest, I'm not even 100% convinced that we need to add
new text.

-Ben