[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: [TLS] draft-vvv-tls-alps-01
From: David Benjamin <davidben () chromium ! org>
Date: 2020-10-12 21:38:20
Message-ID: CAF8qwaBjA9SXmA9CB0QN1urD=v6tVb4P9rKZ-bnTsVPREMK=CQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
[Attachment #5 (text/html)]
<div dir="ltr"><span \
id="gmail-docs-internal-guid-902c0b2b-7fff-0c9d-678e-731e61ec32f0"><p dir="ltr" \
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Hi \
all,</span></p><br><p dir="ltr" \
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">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.</span></p><p dir="ltr" \
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"><a \
href="https://tools.ietf.org/html/draft-vvv-tls-alps-01">https://tools.ietf.org/html/draft-vvv-tls-alps-01</a><br></span></p><br><p \
dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">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:</span></p><br><ul \
style="margin-top:0px;margin-bottom:0px"><li dir="ltr" \
style="list-style-type:disc;font-family:Arial;color:rgb(0,0,0);background-color:transp \
arent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre"><p \
dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">We \
add a CEE tag to the TLS 1.3 column in the IANA registry.</span></p></li><li \
dir="ltr" style="list-style-type:disc;font-family:Arial;color:rgb(0,0,0);background-co \
lor:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre"><p \
dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">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.)</span></p></li><li \
dir="ltr" style="list-style-type:disc;font-family:Arial;color:rgb(0,0,0);background-co \
lor:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre"><p \
dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">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.)</span></p></li></ul><br><p \
dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">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.</span></p><br><p dir="ltr" \
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">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.</span></p><br><p dir="ltr" \
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Section \
4.6.1 of RFC8446 has the following text:</span></p><p dir="ltr" \
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><a \
href="https://tools.ietf.org/html/rfc8446#section-4.6.1" \
style="text-decoration-line:none"><span \
style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font \
-variant-east-asian:normal;text-decoration-line:underline;vertical-align:baseline;whit \
e-space:pre-wrap">https://tools.ietf.org/html/rfc8446#section-4.6.1</span></a></p><br><p \
dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"> \
Note: Although the resumption master secret depends on the client's</span></p><p \
dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"> \
second flight, a server which does not request client authentication</span></p><p \
dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"> \
MAY compute the remainder of the transcript independently and then</span></p><p \
dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"> \
send a NewSessionTicket immediately upon sending its Finished rather</span></p><p \
dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"> \
than waiting for the client Finished. This might be appropriate in</span></p><p \
dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"> \
cases where the client is expected to open multiple TLS connections</span></p><p \
dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"> \
in parallel and would benefit from the reduced overhead of a</span></p><p dir="ltr" \
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"> \
resumption handshake, for example.</span></p><br><p dir="ltr" \
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">This \
relies on the server being able to predict the client Finished flight in 0-RTT \
handshakes. Two risks here:</span></p><br><ul \
style="margin-top:0px;margin-bottom:0px"><li dir="ltr" \
style="list-style-type:disc;font-family:Arial;color:rgb(0,0,0);background-color:transp \
arent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre"><p \
dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Whether \
EncryptedExtensions is sent must be deterministic (as in our \
formulation).</span></p></li><li dir="ltr" \
style="list-style-type:disc;font-family:Arial;color:rgb(0,0,0);background-color:transp \
arent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre"><p \
dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">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.</span></p></li></ul><br><p dir="ltr" \
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">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.</span></p><br><p dir="ltr" \
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">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 </span><a \
href="https://mailarchive.ietf.org/arch/msg/tls/hymweZ66b2C8nnYyXF8cwj7qopc" \
style="text-decoration-line:none"><span \
style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font \
-variant-east-asian:normal;text-decoration-line:underline;vertical-align:baseline;whit \
e-space:pre-wrap">https://mailarchive.ietf.org/arch/msg/tls/hymweZ66b2C8nnYyXF8cwj7qopc</span></a><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">, \
and </span><a href="https://github.com/openssl/openssl/pull/6944#issuecomment-413858136" \
style="text-decoration-line:none"><span \
style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font \
-variant-east-asian:normal;text-decoration-line:underline;vertical-align:baseline;white-space:pre-wrap">this \
comment</span></a><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"> \
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 </span><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-style:ital \
ic;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">second</span><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"> \
application round-trip rather than the first:</span></p><br><p dir="ltr" \
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font \
face="monospace">ClientHello<br>GET /request1 HTTP/1.1<br> \
ServerHello..Finished<br> HTTP/1.1 200 \
OK<br>EndOfEarlyData..Finished<br>GET /request2 HTTP/1.1<br> \
NewSessionTicket<br> HTTP/1.1 200 \
OK</font><br></p><br><p dir="ltr" \
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">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 <i style="">further</i> delay it to some late read. \
</span><span style="background-color:transparent;color:rgb(0,0,0);font-family:Arial;white-space:pre-wrap">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.</span></p><br><p dir="ltr" \
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Thoughts?</span></p><br><p \
dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span \
style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu \
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">David</span></p></span><br \
class="gmail-Apple-interchange-newline"></div>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic