Re: [TLS] SNI and Resumption/0-RTT

Victor Vasiliev <vasilvv@google.com> Wed, 23 November 2016 22:46 UTC

Return-Path: <vasilvv@google.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 60AB012949E for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 14:46:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 FB83pJHeF0MH for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 14:46:20 -0800 (PST)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B357C12940F for <tls@ietf.org>; Wed, 23 Nov 2016 14:46:20 -0800 (PST)
Received: by mail-qt0-x235.google.com with SMTP id n6so25323759qtd.1 for <tls@ietf.org>; Wed, 23 Nov 2016 14:46:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FI/6A3Z2M43lP2muCYcLQj2nOjmHQB69bRgqeFDhgTg=; b=dAkAbPxVKcBs5fWBw646fBQGmJn/kdp2DlcaUfp35oBg2ngU8IDM8e3dGd8RJn/tcE IvsI/GZWRFaVrN2UIucHbh2BZq1hHk74NmcTimvBxmyNSaglxtjFRVi/6jJ/xCoBoTk7 IKMKGzQu0wWrj4AmJZ15NWPRqxHnwCZsuqwG8RcV7tm9lWuk/rms+EXuTRzNhorb5pAD RyVV8Hs/EgTwWPBjSArfLVuIAjt041rfOKx1Xrp2ylim9qTWFDn81oJUJTl1XlETuT7K aUwsF624JSklnFFZQ7hbQimvanHrXbpAdrS0Oate4Ix3r/ZgpZ6dL4jPDXQUzdQNx84d LS4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FI/6A3Z2M43lP2muCYcLQj2nOjmHQB69bRgqeFDhgTg=; b=DBW1LwQJ0v6HbYVdPozozSVJc6bj69YZBGodIssb0fLWLkvzHll7My9yd03h/OafdQ 9AZZYFtBVHyShr49eTq78dD2VMKVQ3UIWNTl0GqdCYf3rEvj2q7AHeMS8IL4nrgYO0VJ yRmnLloMJgbnNQH9dndnzrUxGTWCk69I9BgOpuw/mcotrKABFvOEDouVaV87Qjcn2f5i UjKuk5PYbidl3t5iYjmTCH3RmZfKt+Ib7rrbUj+Ne3MjZpeme3HfiLfZxuXHbMBNoxBk 2TqKQyIKDAPk0573ebFv5wS5raZ9yD2KKMNL83tHICjtvKOPWmtLDrGx1ylpyoFSEHZd C9aA==
X-Gm-Message-State: AKaTC012mF17kAxIrUcZXuwuIghUerqS18IbhmC5Z5fjR3kp7PcHn1wohB52yJDDIvgqDfE/x9DE5ugKZl3W8KXa
X-Received: by 10.237.53.56 with SMTP id a53mr4637979qte.85.1479941179645; Wed, 23 Nov 2016 14:46:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.55.157.11 with HTTP; Wed, 23 Nov 2016 14:46:19 -0800 (PST)
In-Reply-To: <CAAZdMadCLSc0QUMs4YZiDqzQMt9nBPPjxwRpeiDbCcNs5N-mEQ@mail.gmail.com>
References: <CABcZeBNroww_zA0BRsMrZPMCrF42b2OZPsQNZ9w0bjPoF+fSHw@mail.gmail.com> <CAAZdMac_nzAYcTUG361EXRgs4nvVFfVCc445roZZdm8uAqZTHA@mail.gmail.com> <4e2b054a-c391-d4f9-c106-d62eb90e2034@akamai.com> <CAAZdMadCLSc0QUMs4YZiDqzQMt9nBPPjxwRpeiDbCcNs5N-mEQ@mail.gmail.com>
From: Victor Vasiliev <vasilvv@google.com>
Date: Wed, 23 Nov 2016 17:46:19 -0500
Message-ID: <CAAZdMaf7+4UR9G6xMR8OmYeSt4WUkmpAid4GN69kEm3_mJSUVA@mail.gmail.com>
To: Benjamin Kaduk <bkaduk@akamai.com>
Content-Type: multipart/alternative; boundary="001a11c0302a4d7fbc0541ffa831"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/x-d27BwMJr1ySryn9N5BbW3UCDA>
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
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: Wed, 23 Nov 2016 22:46:22 -0000

It seems that this issue has not been so far successfully resolved, and to
the
best of my knowledge it has not been discussed during the meeting in Seoul.
 I
still believe that this is a valuable feature, and our experience with 0-RTT
handshake deployment in QUIC has indicated that it's basically required to
make
0-RTT work for YouTube videos.

So far, we have considered three options in this thread:
  (1) Retain RFC 6066 restriction on SNI,
  (2) Allow resumption for different SNI provided it was negotiated in the
      ticket,
  (3) Always allow resumption for different SNI.
In both (2) and (3), the certificate for the original ticket issuer would
have
to be valid for the new server name, of course.

I believe that (2) will result in a higher resumption success rate than (3),
since for the servers that do not support shared resumption key, (3) would
result in losing session tickets to unsuccessful resumption.

For concreteness, I wrote a pull request that describes (2):
    <https://github.com/tlswg/tls13-spec/pull/777>