[TLS] RFC7301 ALPN conflicting objectives about app-specific server certificates
mrex@sap.com (Martin Rex) Tue, 30 June 2015 20:26 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 F27C81B2D1E for <tls@ietfa.amsl.com>; Tue, 30 Jun 2015 13:26:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level:
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 RzIsgJ4kVQ0F for <tls@ietfa.amsl.com>; Tue, 30 Jun 2015 13:26:27 -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 04EFA1B2D7B for <tls@ietf.org>; Tue, 30 Jun 2015 13:26:16 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (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 E8D6F44724 for <tls@ietf.org>; Tue, 30 Jun 2015 22:26:13 +0200 (CEST)
X-purgate-ID: 152705::1435695973-00005316-A2004B17/0/0
X-purgate-size: 3323
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 mail05.wdf.sap.corp (Postfix) with ESMTP id D9B6D42F9A for <tls@ietf.org>; Tue, 30 Jun 2015 22:26:13 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id D07251A1AD; Tue, 30 Jun 2015 22:26:13 +0200 (CEST)
To: tls@ietf.org
Date: Tue, 30 Jun 2015 22:26:13 +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: <20150630202613.D07251A1AD@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Y6Q9nPSsYk32r2nvhY4h5SVwtT8>
Subject: [TLS] RFC7301 ALPN conflicting objectives about app-specific server certificates
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: <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, 30 Jun 2015 20:26:30 -0000
I'm currently implementing support for ALPN in our middlware, and I'm wondering how to account for ALPN in the client side session caching management, because rfc7301 describes two mutually exclusive objectives and the ALPN protocol does not provide a means for the server to disambiguate the desired semantics in the ServerHello response. rfc7301, https://tools.ietf.org/html/rfc7301#section-1 Section 1. last sentence of paragraph 2 (end of page 2): Further, it would be advantageous to allow certificate selection based on the negotiated application protocol. Section 1, last sentence of paragraph 4 (last paragraph): The application protocol negotiation can thus be accomplished within the TLS handshake, without adding network round-trips, and allows the server to associate a different certificate with each application protocol, if desired. is in conflict with Section 3.1, last paragraph https://tools.ietf.org/html/rfc7301#page-5 Unlike many other TLS extensions, this extension does not establish properties of the session, only of the connection. When session resumption or session tickets [RFC5077] are used, the previous contents of this extension are irrelevant, and only the values in the new handshake messages are considered. Currently, my client-side session cache management, and the decision whether to propose a TLS session to the server for resumption, is based on a match of the application supplied "target name" which is usually an fqdn hostname, but could also be an abbreviated hostname or an IP address. When the server does not resume the proposed session, and performs a full handshake instead, my client purges the previous cached session and adds the newly established session to the client-side session cache instead. If the server uses distict server certificates per application protocol and properly(!!) performs a full handshake if the server certificate does not fit the requested application protocol, then alternating requests with two different protocols to the same server will result in constant full TLS handshakes. But what can also easily happen, is that the server is inappropriately sharing the server-side session cache an incorrectly resuming sessions associated with the wrong server certificate (a different certificate than what the server would select if it would perform a full TLS handshake), and if the different server certificate attributes are relevant to the application protocol, then this would result in random client-side errors (failed server certificate validation) when there is already a session for the _other_ app in the client-side session cache. I've seen incorrect server-side session cache pooling before, e.g. a few years ago between docs.google.com and www.google.com. Essentially, I believe that tagging of the session with the ALPN negotiated protocol to result in more "predictable" behaviour, because it will not interfere with client-side session cache management and not result in occasional confusion should other server implementors ever make their servers use different server certificates for different ALPN-negotiated protocols. -Martin
- [TLS] RFC7301 ALPN conflicting objectives about a… Martin Rex
- Re: [TLS] RFC7301 ALPN conflicting objectives abo… Andrei Popov
- Re: [TLS] RFC7301 ALPN conflicting objectives abo… Martin Rex
- Re: [TLS] RFC7301 ALPN conflicting objectives abo… Viktor Dukhovni
- Re: [TLS] RFC7301 ALPN conflicting objectives abo… Martin Rex
- Re: [TLS] RFC7301 ALPN conflicting objectives abo… Viktor Dukhovni
- Re: [TLS] RFC7301 ALPN conflicting objectives abo… Andrei Popov
- Re: [TLS] RFC7301 ALPN conflicting objectives abo… Martin Rex
- Re: [TLS] RFC7301 ALPN conflicting objectives abo… Viktor Dukhovni