Re: [TLS] SNI and tickets and resumption

mrex@sap.com (Martin Rex) Fri, 08 August 2014 23:25 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 E3D4B1A015D for <tls@ietfa.amsl.com>; Fri, 8 Aug 2014 16:25:07 -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 Km8benh2tgIy for <tls@ietfa.amsl.com>; Fri, 8 Aug 2014 16:25:06 -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 0A39B1A014E for <tls@ietf.org>; Fri, 8 Aug 2014 16:25:05 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s78NP3WI020124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Aug 2014 01:25:03 +0200 (MEST)
In-Reply-To: <20140808230653.C508F1ADFC@ld9781.wdf.sap.corp>
To: mrex@sap.com
Date: Sat, 9 Aug 2014 01:25:03 +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: <20140808232503.6480A1ADFC@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8xPpdJGOs0a4TAL3qv9K0Tnjkq4
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:25:08 -0000

Ooops.  Somehow the previous message wasn't what I wanted to say.

When I implemented support for TLS extension SNI (at the lower levels
or our software stack), then I implemented the "principle of least
surprise" in the following fashion:

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.

-Martin



Martin Rex wrote:
> 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.