Re: [TLS] SNI and tickets and resumption

mrex@sap.com (Martin Rex) Fri, 08 August 2014 23:07 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 4CB2B1A014E for <tls@ietfa.amsl.com>; Fri, 8 Aug 2014 16:07:01 -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 o_p8jUDHVjLr for <tls@ietfa.amsl.com>; Fri, 8 Aug 2014 16:06:59 -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 A110D1A01AA for <tls@ietf.org>; Fri, 8 Aug 2014 16:06:58 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s78N6rVR019106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Aug 2014 01:06:53 +0200 (MEST)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7185A0C8523@USMBX1.msg.corp.akamai.com>
To: "Salz, Rich" <rsalz@akamai.com>
Date: Sat, 9 Aug 2014 01:06:53 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140808230653.C508F1ADFC@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KE4zj4IOT3zS1jEdenvzlMN5720
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: Fri, 08 Aug 2014 23:07:02 -0000

Salz, Rich <rsalz@akamai.com> asked:
>
> Can a client connect with an SNI extension and then later on resume
> or send a ticket with a different SNI value?

AGL responded:
>
> At Google, we share ticket keys between servers, but the servers will
> reject a resumption if any part of the ClientHello causes a different
> certificate to be selected than was presented on the original
> connection.


Salz, Rich wrote:
>
> We do the same thing, but wasn't sure if it was legit. 


The words you're using are sufficiently ambiguous to get me worried.

Since the specification of the TLS extension "server name indication"
is also somewhat wrong (which I only noticed when I implemented it),
I would appreciate to get this clarified.

On a mismatch of SNI in combination of resumption with the original SNI
value (and I include _absent_ SNI on an initial SSLv2 CLIENT-HELLO
in this count!), the server should behave according to the
"Principle of least surprise", and **NOT** reject the connection
(i.e. *NOT* abort with a fatal alert).

If the server doesn't use SNI at all (which includes not supporting
TLS extension SNI), then it should continue to ignore SNI on resumption.


If the server uses SNI on initial full handshakes (those without any
kind of resumption proposed by the client), then the server should
perform a full TLS handshake if SNI differs from what was used for
the session that was proposed for resumption.


-Martin