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 (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: <20161025100742.993131A564@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
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