Re: [TLS] SNI and Resumption/0-RTT
mrex@sap.com (Martin Rex) Tue, 25 October 2016 10:07 UTC
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB8212943C for <tls@ietfa.amsl.com>; Tue, 25 Oct 2016 03:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level:
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 hi2OUHoCavJk for <tls@ietfa.amsl.com>; Tue, 25 Oct 2016 03:07:45 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2506112943D for <tls@ietf.org>; Tue, 25 Oct 2016 03:07:45 -0700 (PDT)
Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3t383M0rf6z25YK; Tue, 25 Oct 2016 12:07:43 +0200 (CEST)
X-purgate-ID: 152705::1477390063-00002B31-10066411/0/0
X-purgate-size: 3999
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3t383L4pRCzkqL5; Tue, 25 Oct 2016 12:07:42 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 993131A564; Tue, 25 Oct 2016 12:07:42 +0200 (CEST)
In-Reply-To: <MWHPR15MB1182E0D0F4FE9DFB7D772CF9AFA80@MWHPR15MB1182.namprd15.prod.outlook.com>
To: Kyle Nekritz <knekritz@fb.com>
Date: Tue, 25 Oct 2016 12:07:42 +0200
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: <20161025100742.993131A564@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/wrHsov1WnxB4lh4xbWBgbQIbsDo>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] SNI and Resumption/0-RTT
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 25 Oct 2016 10:07:47 -0000
Kyle Nekritz wrote: > > I do think this should be allowed if the client is satisfied with the > previous identities presented. We currently allow resumption across > domains supported by our wildcard certificate (I believe this is fairly > common practice), and our clients take advantage of this to improve their > resumption rate. In regards to the referenced paper, I don't think this > is any more dangerous than the wildcard certificate itself as a full > handshake would succeed anyway. I don't think it's entirely necessary > for the server to opt-in to this either, if the server wants it can > simply reject the resumption attempt. I think it is a bad idea to look at this purely from the perspective of whether this represents an obvious attack vector. And there are two entirely *independent* decisions involved. (1) whether the TLS client proposes resumption for a session (i.e. client-side cache management) (2) whether the TLS server agrees to a proposed resumption or whether it performs a full handshake instead And there are _different_ security trade-offs in these two distinct decisions. As I previously described my position, I'm perfectly OK with a server performing a resumption if the full handshake would cause the server to send/present the very same TLS server certificate as in the full handshake that created the session that is proposed for resumption ... and that is actually the behaviour which I implemented, and what comes out naturally if you implement TLS extension SNI support _outside_ of the TLS stack on the server side. However, I believe that the server agreeing to resumption with a different SNI hostname is a use case, that with a sensible generic TLS client, should never actually occur in practice. Except for bugs or design flaws in the client-side session cache management maybe. The client does _not_ know which TLS server certificates the server has available, and what criteria it will apply for selecting one or the other. The existence of a wildcard certificate does not unconditionally preclude existence of host-specific certificates for specific services that are technically covered by the wildcard. I really dislike seemingly non-deterministic behaviour, and therefore try to avoid it as much as possible in whatever I implement. The decision to accept a particular server certificate for one specific hostname/target does not (should not) necessarily apply to *each* other possible servername covered/conveyed by that server certificate. Special-casing stuff makes the behaviour also difficult to comprehend for end-users / consumers (and implementers get it wrong more easily). What if the server certificate is "manually" confirmed by the end-user (for whatever reason: it's self-signed/untrusted or from DANE rather that PKIX) should that "acceptance" still/also transcend to all other hostnames (why or why not)? My client-side TLS session cache management (which I implemented above the TLS stack), uses the target hostname as one of the session cache lookup parameters, and I don't think it would be sensible to propose arbitrary sessions for resumption. The performance overhead for a full handshake per hostname is completely negligible (and if the server operator cares, he could simply avoid spreading content over distinct server hostnames). What I found painful instead, is the server-side behaviour implemented by Microsoft IIS / SChannel in the past, because when configured for optional client certificates, the server exhibits Alzheimer towards certificate-less clients (or at least it did so in the past), because it would force each client without client cert through a full renegotiation handshake after resumption for each new connection, failing to memorize that the resumed session was created by renegotiation where the server did ask for a client cert and the client did turn down that request. -Martin
- [TLS] SNI and Resumption/0-RTT Eric Rescorla
- Re: [TLS] SNI and Resumption/0-RTT Andrei Popov
- Re: [TLS] SNI and Resumption/0-RTT Eric Rescorla
- Re: [TLS] SNI and Resumption/0-RTT Andrei Popov
- Re: [TLS] SNI and Resumption/0-RTT Eric Rescorla
- Re: [TLS] SNI and Resumption/0-RTT Martin Thomson
- Re: [TLS] SNI and Resumption/0-RTT Ilari Liusvaara
- Re: [TLS] SNI and Resumption/0-RTT Martin Thomson
- Re: [TLS] SNI and Resumption/0-RTT Martin Rex
- Re: [TLS] SNI and Resumption/0-RTT Ilari Liusvaara
- Re: [TLS] SNI and Resumption/0-RTT Martin Rex
- Re: [TLS] SNI and Resumption/0-RTT Ilari Liusvaara
- Re: [TLS] SNI and Resumption/0-RTT Ilari Liusvaara
- Re: [TLS] SNI and Resumption/0-RTT Christian Huitema
- Re: [TLS] SNI and Resumption/0-RTT Ilari Liusvaara
- Re: [TLS] SNI and Resumption/0-RTT Christian Huitema
- Re: [TLS] SNI and Resumption/0-RTT Andrei Popov
- Re: [TLS] SNI and Resumption/0-RTT Victor Vasiliev
- Re: [TLS] SNI and Resumption/0-RTT Kyle Nekritz
- Re: [TLS] SNI and Resumption/0-RTT Martin Rex
- Re: [TLS] SNI and Resumption/0-RTT Benjamin Kaduk
- Re: [TLS] SNI and Resumption/0-RTT Victor Vasiliev
- Re: [TLS] SNI and Resumption/0-RTT Victor Vasiliev
- Re: [TLS] SNI and Resumption/0-RTT Martin Thomson