[TLS] draft-vvv-tls-alps-01

David Benjamin <davidben@chromium.org> Mon, 12 October 2020 21:38 UTC

Return-Path: <davidben@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F335D3A09FD for <tls@ietfa.amsl.com>; Mon, 12 Oct 2020 14:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.439
X-Spam-Status: No, score=-10.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xPOC6clB8p1A for <tls@ietfa.amsl.com>; Mon, 12 Oct 2020 14:38:37 -0700 (PDT)
Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) (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 75FC93A09FC for <tls@ietf.org>; Mon, 12 Oct 2020 14:38:37 -0700 (PDT)
Received: by mail-pl1-x644.google.com with SMTP id p11so9404680pld.5 for <tls@ietf.org>; Mon, 12 Oct 2020 14:38:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=fG6HN0Qfuk3CJKileTwFpwfdrB+bbbWpzYXOM4MMPgg=; b=H2N0B1Whfzw0DVQrpGJY0wUcXF97MYDB10wmHAODTtkV5WKi2MoaIvSn3Bf1Yy1p5c P71zuo2VWseNqMFO1H5E08CFJrSRw5Ui2Q+kmw+2wNNnNV1M3aifWUMSkeBhebf/+Ntp pnp+ZkOCbOb7Zj0cO8qH7h+JvesS+QpaB1JYg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=fG6HN0Qfuk3CJKileTwFpwfdrB+bbbWpzYXOM4MMPgg=; b=T3oFOYr6FdvlqsSdxT0324edTFwwAyTElbi9TzW5Gg8wzWcezHp7lyQaBRszbi/pq+ nLyaaB4Z6swaee1fenquef4FFarvVRkWKtiKffWU1CQDe4pGgVxCU2fkC5KiZdZE44Fr +8UNsLGXhZ4EWD1DwmJhVuemfmRkgnKtOVqsymO1DxZgpCHfZ9UXNENLimXxVdyRL75c 0eE/8rPjSNZkXjKfYd1+EgTtuyWdGmycgIXIR5cz0XJOPqHXCcTnjWBcLhEwGVtMEw8o Xs8B4lzR5MOMzQID9Z7kObz3RLqlKqgUjMGayFipPDdG3QYveoiEwAJMaakeiELNr95e vSeQ==
X-Gm-Message-State: AOAM533zdSDwlxxJROXCz865kwUHz5JA0zqIuNjnr54FhvJ1nR/rk0Mj Xay+AVaH2S2lNkoUlvsbEM5c22AH00fxZ00jL5LYU8XW+UV9
X-Google-Smtp-Source: ABdhPJzmNBO18S8hBDNbvzRoo38oXtvOoXvDke6xD2BnRK2TlCG9ECWf4QxuHWj769DkGsoHwFCMjbdTg+1BtNa/6YU=
X-Received: by 2002:a17:902:6b4a:b029:d3:e8f4:3356 with SMTP id g10-20020a1709026b4ab02900d3e8f43356mr26090932plt.0.1602538716120; Mon, 12 Oct 2020 14:38:36 -0700 (PDT)
MIME-Version: 1.0
From: David Benjamin <davidben@chromium.org>
Date: Mon, 12 Oct 2020 17:38:20 -0400
Message-ID: <CAF8qwaBjA9SXmA9CB0QN1urD=v6tVb4P9rKZ-bnTsVPREMK=CQ@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ea50f705b1801e6f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WKEC6X9a5ILsPthn-XyrF2N0fcU>
Subject: [TLS] draft-vvv-tls-alps-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 12 Oct 2020 21:38:40 -0000

Hi all,

Victor and I recently published draft-vvv-tls-alps-01. It has a couple of
changes that I wanted to get the WG’s thoughts on. The changes are
switching the bespoke ClientApplicationSettings message to a client
EncryptedExtensions message and clarifying the 0-RTT handling.


I think it was EKR who suggested a client EncryptedExtensions message, so
future extensions can more easily add to the client Finished leg. A new
message means picking when it is sent, and a new extensions block means
picking when extensions are allowed. We’ve initially gone with:


   We add a CEE tag to the TLS 1.3 column in the IANA registry.

   The client sends EncryptedExtensions, possibly empty, if and only if the
   server sent at least one CEE-tagged extension in server
   EncryptedExtensions. (No unsolicited server extensions, so the client will
   know the status of each extension.)

   The client may send an extension in EncryptedExtensions if the server
   sent the corresponding extension in server EncryptedExtensions. (Whether it
   is mandatory or optional once negotiated is the extension’s business.)

Other formulations may also work. We picked this to avoid an optional
message (see half-RTT tickets below), and to try to match the existing

For 0-RTT, ALPS aims to align with ALPN where we carry over the ticket
state (like ALPN, ALPS is resolved before any application data) and decline
0-RTT on mismatch. That leaves the question of resending the information
(receiver checks it matches) vs omitting it (receiver implicitly carries it
over). ALPN does the former, but we’ve currently gone with the latter for
ALPS. Both seem comparable implementation-wise, but we picked this for
fewer bytes on the wire, and to avoid breaking half-RTT tickets. We’d
particularly like to hear the WG’s thoughts on this last point.

Section 4.6.1 of RFC8446 has the following text:


   Note: Although the resumption master secret depends on the client's

   second flight, a server which does not request client authentication

   MAY compute the remainder of the transcript independently and then

   send a NewSessionTicket immediately upon sending its Finished rather

   than waiting for the client Finished.  This might be appropriate in

   cases where the client is expected to open multiple TLS connections

   in parallel and would benefit from the reduced overhead of a

   resumption handshake, for example.

This relies on the server being able to predict the client Finished flight
in 0-RTT handshakes. Two risks here:


   Whether EncryptedExtensions is sent must be deterministic (as in our

   Extension order is not fixed. If we ever have two client encrypted
   extensions sent over 0-RTT, the server cannot predict which will go first.

We thus punted this in -01 by not sending the redundant extension in 0-RTT
at all. Another option would be locking the client EE extension order. But
I think we should decide whether half-RTT tickets are a constraint we want
to carry going forward.

Half-RTT tickets were originally added for a stateless reject flow in QUIC
that no longer applies. We’ve since found it useful for 0-RTT, to avoid
some problematic I/O patterns. (See
https://mailarchive.ietf.org/arch/msg/tls/hymweZ66b2C8nnYyXF8cwj7qopc, and this
<https://github.com/openssl/openssl/pull/6944#issuecomment-413858136> from
I think an NGINX developer.) We’ve since realized we can avoid the
surprising I/O patterns by deferring NewSessionTicket to the next
application write and have done so in BoringSSL for 1-RTT. For 0-RTT, we
currently still use half-RTT tickets because the cost is connections don’t
deliver tickets until the second application round-trip rather than the

GET /request1 HTTP/1.1
                              HTTP/1.1 200 OK
GET /request2 HTTP/1.1
                              HTTP/1.1 200 OK

Delaying this seems surprising and not ideal. We already see that
post-handshake NST is itself surprising to application developers, since
the client only picks up tickets on the first read. This would *further*
delay it to some late read. It’s also something the RFC explicitly says you
can do, and dropping this would contradict that decision. At the same time,
the prediction bits are goofy and constraining.