Re: [TLS] SNI and tickets and resumption
Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 11 August 2014 17:52 UTC
Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985D31A049D for <tls@ietfa.amsl.com>; Mon, 11 Aug 2014 10:52:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6] autolearn=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 TJ6lz3f8iYZf for <tls@ietfa.amsl.com>; Mon, 11 Aug 2014 10:52:03 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08611A048D for <tls@ietf.org>; Mon, 11 Aug 2014 10:52:02 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EA3D72AB2BD; Mon, 11 Aug 2014 17:52:00 +0000 (UTC)
Date: Mon, 11 Aug 2014 17:52:00 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20140811175200.GQ14392@mournblade.imrryr.org>
References: <20140808232503.6480A1ADFC@ld9781.wdf.sap.corp> <m28umvy8qs.fsf@usma1mc-0csx92.kendall.corp.akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <m28umvy8qs.fsf@usma1mc-0csx92.kendall.corp.akamai.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tgFhdQSpcBrtSzyETqNNrxk7CNE
Subject: Re: [TLS] SNI and tickets and resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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: <http://www.ietf.org/mail-archive/web/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, 11 Aug 2014 17:52:06 -0000
On Mon, Aug 11, 2014 at 12:02:03AM -0400, Brian Sniffen wrote: > > Essentially, whenever a full handshake would result in the use of the > > same server certificate as the resumption proposed by the client, > > my server will perform session resumption, and ingnore SNI mismatches. > > So if a server has a giant SAN cert for `eff.org` and `nsa.gov`, and a > session with one is resumed to the other---that's unsurprising? I don't > see a path all the way through to an attack, but it leads me to worry > about a web app and a web server interacting in this way. With DANE TLSA records of the form: _443._tcp.www.nsa.gov. IN CNAME _443._tcp.www.example.net. _443._tcp.www.eff.org. IN CNAME _443._tcp.www.example.net. _443._tcp.www.example.net. IN TLSA DANE-EE(3) SPKI(1) SHA2-256(1) {blob} and supposing that at some future date, browsers support RFC 6698 and updates, the name in the server certificate is entirely irrelevant, the name to key binding is in DNS. The HTTPS server is then authenticated by its public key alone. The clients will then send SNI with either "www.nsa.gov" or "www.eff.org" (on the off chance that the server cares), but there is nothing a-priori wrong with a single certificate associated with multiple domains (as unlikely as it may seem that eff.org and nsa.gov would choose the same hosting provider). > On the other hand, RFC 6066 also says: > > A server that implements [SNI] MUST NOT accept the request > to resume the session if the server_name extension contains a > different name. Instead, it proceeds with a full handshake to > establish a new session. Some client caches are poorly designed, and their cache lookup key might be only the peer IP:port and not the associated domain or other relevant data. Servers should tolerate this at least to the extent performing a full handshake instead of resumption. Resuming with mismatched SNI is perhaps in conflict with 6066, but seems harmless from a server perspective, the error is on the client side, and if there are security consequences, it seems to me that the exposure is there as soon as the client offers to resumt the mismatched session. I think it is the client that SHOULD NOT resume sessions across mismatched SNI values, since it can no longer be sure it is connected to the intended server. I see little harm in the server saying yes if the certificate is the same in either case. -- Viktor.
- [TLS] SNI and tickets and resumption Salz, Rich
- Re: [TLS] SNI and tickets and resumption Adam Langley
- Re: [TLS] SNI and tickets and resumption Salz, Rich
- Re: [TLS] SNI and tickets and resumption Martin Thomson
- Re: [TLS] SNI and tickets and resumption Martin Rex
- Re: [TLS] SNI and tickets and resumption Martin Rex
- Re: [TLS] SNI and tickets and resumption Adam Langley
- Re: [TLS] SNI and tickets and resumption Martin Rex
- Re: [TLS] SNI and tickets and resumption Sajeev S
- Re: [TLS] SNI and tickets and resumption Brian Sniffen
- Re: [TLS] SNI and tickets and resumption Antoine Delignat-Lavaud
- Re: [TLS] SNI and tickets and resumption Martin Rex
- Re: [TLS] SNI and tickets and resumption Martin Rex
- Re: [TLS] SNI and tickets and resumption Viktor Dukhovni
- Re: [TLS] SNI and tickets and resumption Viktor Dukhovni