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.