[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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. https://tools.ietf.org/html/draft-vvv-tls-alps-01 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 scheme. 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: https://tools.ietf.org/html/rfc8446#section-4.6.1 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 formulation). - 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 comment <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 first: ClientHello GET /request1 HTTP/1.1 ServerHello..Finished HTTP/1.1 200 OK EndOfEarlyData..Finished GET /request2 HTTP/1.1 NewSessionTicket 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. Thoughts? David
- [TLS] draft-vvv-tls-alps-01 David Benjamin