[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