Re: [TLS] SNI and tickets and resumption

mrex@sap.com (Martin Rex) Mon, 11 August 2014 18:32 UTC

Return-Path: <mrex@sap.com>
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 1A9C11A0735 for <tls@ietfa.amsl.com>; Mon, 11 Aug 2014 11:32:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 mJo_dJ4pfXYM for <tls@ietfa.amsl.com>; Mon, 11 Aug 2014 11:32:14 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 444881A0066 for <tls@ietf.org>; Mon, 11 Aug 2014 11:32:14 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s7BIVxig019139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Aug 2014 20:31:59 +0200 (MEST)
In-Reply-To: <53E8467B.2090609@delignat-lavaud.fr>
To: Antoine Delignat-Lavaud <antoine@delignat-lavaud.fr>
Date: Mon, 11 Aug 2014 20:31:59 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20140811183159.145C81AE02@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/glHAST80fwzLH6W3MjkCfK_XCQ0
Cc: Adam Langley <agl@imperialviolet.org>, "TLS@ietf.org \(tls@ietf.org\)" <tls@ietf.org>
Subject: Re: [TLS] SNI and tickets and resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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 18:32:16 -0000

Antoine Delignat-Lavaud wrote:
> Le 8/11/2014 5:02 AM, Brian Sniffen a écrit :
>>> 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.
> 
> Yes, it *is* indeed unsurprising: this behavior is the standard in SPDY 
> and in the current HTTP2 draft even though it goes against the spirit of 
> RFC 6066 -- see my message in the thread "inter-protocol attacks".

It is not against the *spirit* (aka underlying design) of TLS extension
server name indication, only against the current, formally provable
defective ad-hoc wording that was used to describe one aspect of the
behaviour (keep in mind that RFC at the "Proposed Standard" maturity
level must be assumed to contain defects such as this one.)


>
> Moreover, current webservers will also proceed with resumption even if 
> the SNI provided by the client would have resulted in the server picking 
> a different certificate.

This behaviour would be against the spirit of rfc6066, and against the
"principle of least surprise".  It would indicate a significant lack of
robustness when fiddling with the session cache lifetime on client or
sorver or when disabling the client-side or server-side session cache
would affect application behaviour / usage scenarios.


>
> This is why resumption can be used to bypass certificate validation
> - this problem is related to yet another TLS API problem with the
> SNI callback. In many cases, the application may not even get to see
> the certificate selection callback from TLS when doing resumption.


According to the TLS specification (last paragraph of Introduction),
the server endpoint identification is something that the application on
top of TLS performs, whereas TLS session caching and resumption is
something that happens transparently within the TLS protocol stack.

  Last sentence of Section 1. Introduction

  https://tools.ietf.org/html/rfc2246#page-4
  https://tools.ietf.org/html/rfc5246#page-5

                   how to interpret the authentication certificates
   exchanged are left up to the judgment of the designers and
   implementors of protocols which run on top of TLS.


The TLS client app ought to perform server endpoint identification
"interpret the authentication certificates exchanged" independent
of whether the TLS connection is established with a full TLS handshake
or and abbreviated TLS handshake (aka TLS session resume).

Normally, I would assume that the client-side session cache is organized/
indexed by the information that is used for server endpoint identification,
and a client should not be proposing session resumption of a cached session
that would fail server endpoint identification.


-Martin