Subject: QUICker connection establishment with out-of-band validation tokens

From: Erik Sy <[email-masked]>
Date: Fri, 12 Apr 2019 16:17:56 +0200

Hi folks,

I suggest introducing out-of-band validation tokens to save a round-trip time during QUIC's connection establishment.
These tokens can be distributed via DNS resolvers or other QUIC servers and can avoid up to 100% of stateless retries during connection establishments. 
Below is a detailed description and evaluation on performance, security, privacy and scalability of this proposal:       
https://svs.informatik.uni-hamburg.de/publications/2019/2019-04-12-Sy-preprint-QUICker_connection_establishment_with_out-of-band_validation_tokens.pdf

Best,
Erik

---

From: Ted Hardie <[email-masked]>
Date: Fri, 12 Apr 2019 09:49:48 -0700

I would like to suggest that the Chairs rule this out of scope for the QUIC
working group to consider during the completion of v1.  Given where we are
in the process, taking on the security and privacy analyses required will
not be a short or simple exercise.

To give a flavor of the analysis required, consider this from the proposal:

To save a round-trip time via the proposed out-of-band tokens, the client
> needs to receive the token before sending the connection request to the corresponding
> QUIC server. Furthermore, clients usually do a domain name query to look
> up the source address before they send their connection request. Thus,
> DNS seems to be a suitable place to distribute out-of-band tokens as the
> connection request often directly follows the corresponding DNS lookup
>

First, this proposal contains major assumptions about the DNS interactions
that would appear to run counter to DNS caching semantics and, more
generally, its distribution by recursive resolvers.  While it might be
possible to overcome the implied limitations by the use of short TTLs and
very aggressive use of EDNS client-subnet, the performance impact of doing
so would be unknown and the privacy implications appear to be poor.
Second, it requires a level of trust between the resolver operator and the
entity generating the tokens that is near total, acknowledged in the draft
here:

Note, that to construct valid out-of-band tokens, the resolver needs to be
> trusted by the server hosting the specific domain name. Thus, the
> respective server operator shared in advance the instructions and the
> secret keys required to generate valid tokens for this domain.
>

There are many additional questions raised by the proposal, including when
to consider including the novel RR as additional data, the interaction with
DNSSEC, and the potential need to use a STUN-like service to get a view of
the IP as it will be seen by the QUIC-speaking server.

I appreciate the work of the authors to consider out-of-bind distribution,
but I do not believe this proposal should be considered by the working
group at this time.

regards,

Ted Hardie
(wearing no hats)

On Fri, Apr 12, 2019 at 7:18 AM Erik Sy <[email-masked]>
wrote:

> Hi folks,
>
> I suggest introducing out-of-band validation tokens to save a round-trip
> time during QUIC's connection establishment.
> These tokens can be distributed via DNS resolvers or other QUIC servers
> and can avoid up to 100% of stateless retries during connection
> establishments.
> Below is a detailed description and evaluation on performance, security,
> privacy and scalability of this proposal:
>

---

From: Erik Sy <[email-masked]>
Date: Fri, 12 Apr 2019 21:21:25 +0200

On 4/12/19 18:49, Ted Hardie wrote:
> I would like to suggest that the Chairs rule this out of scope for the
> QUIC working group to consider during the completion of v1.  Given
> where we are in the process, taking on the security and privacy
> analyses required will not be a short or simple exercise.
>
>     To save a round-triptime via the proposed out-of-band tokens, the
>     client needs to receive the token before sending the connection
>     request to the corresponding QUIC server. Furthermore, clients
>     usually do a domain name query to look up the source address
>     before they send their connection request. Thus, DNS seems to be a
>     suitable place to distribute out-of-band tokens as the
>     connectionrequest often directly follows the corresponding DNS
>     lookupFirst, this proposal contains major assumptions about the
>     DNS interactions that would appear to run counter to DNS caching
>     semantics and, more generally, its distribution by recursive
>     resolvers.  While it might be possible to overcome the implied
>     limitations by the use of short TTLs and very aggressive use of
>     EDNS client-subnet, the performance impact of doing so would be
>     unknown and the privacy implications appear to be poor.  Second,
>     it requires a level of trust between the resolver operator and the
>     entity generating the tokens that is near total, acknowledged in
>     the draft here:
>
The article proposes two different distribution mechanisms for
out-of-band tokens. The distribution via DNS resolvers is certainly more
difficult to realize as it is a cross-layer performance optimization.
The second proposed distribution mechanism using QUIC connections to
other hostnames is much simpler to implement. Thus, I suggest to
consider this mechanism to be in scope for QUIC v1.
>
>     Note, that to construct valid out-of-band tokens, the resolver
>     needs to be trusted by the server hosting the specific domainname.
>     Thus, the respective server operator shared in advance the
>     instructions and the secret keys required to generate validtokens
>     for this domain.
>
>
To put this in context, the QUIC server allows another 'trusted' entity
to issue valid tokens, however the QUIC server can always revoke this
trust-relation with immediate
effect.<https://www.dict.cc/englisch-deutsch/with+immediate+effect.html>
> There are many additional questions raised by the proposal, including
> when to consider including the novel RR as additional data, the
> interaction with DNSSEC, and the potential need to use a STUN-like
> service to get a view of the IP as it will be seen by the
> QUIC-speaking server. 
>
> I appreciate the work of the authors to consider out-of-bind
> distribution, but I do not believe this proposal should be considered
> by the working group at this time. 
>
> regards,
>
> Ted Hardie
> (wearing no hats)
>  
>
> On Fri, Apr 12, 2019 at 7:18 AM Erik Sy <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi folks,
>
>     I suggest introducing out-of-band validation tokens to save a
>     round-trip time during QUIC's connection establishment.
>     These tokens can be distributed via DNS resolvers or other QUIC
>     servers and can avoid up to 100% of stateless retries during
>     connection establishments.
>     Below is a detailed description and evaluation on performance,
>     security, privacy and scalability of this proposal:

---

From: Ted Hardie <[email-masked]>
Date: Fri, 12 Apr 2019 13:39:02 -0700

Thanks for your rapid reply.  More in-line.

> consider this mechanism to be in scope for QUIC v1.
The proposal for an EXTERNAL_TOKEN frame has security properties and
performance properties that would still need considerable analysis.  If the
token is associated with a hostname which is already present in the
certificate for the TLS session, it's not clear why the token would need to
be presented on a new connection.  If it is not, then the client's trust
that it is okay to receive a token for example.com from mumblefratz.example
is based on very unclear principles.  While you have addressed why you
believe the client is not harmed by presenting a bad token, it is not clear
to me that this is true for servers nor that server's behavior toward those
clients presenting bad tokens will be consistent.

I must reiterate my statement that I don't think this should in scope for
v1 at all.

regards,

Ted

---

From: Erik Sy <[email-masked]>
Date: Fri, 12 Apr 2019 23:19:25 +0200

> On Fri, Apr 12, 2019 at 12:21 PM Erik Sy <[email-masked]
> performance properties that would still need considerable analysis.
Yes, some performance properties are still unknown. Do you have some
missing performance analysis in mind which can be conducted before QUIC
v1 is deployed on the web?
>   If the token is associated with a hostname which is already present
> in the certificate for the TLS session, it's not clear why the token
> would need to be presented on a new connection.  If it is not, then
> the client's trust that it is okay to receive a token for example.com
> <http://example.com> from mumblefratz.example is based on very unclear
> principles.  While you have addressed why you believe the client is
> not harmed by presenting a bad token, it is not clear to me that this
> is true for servers nor that server's behavior toward those clients
> presenting bad tokens will be consistent.

For out-of-band tokens it is assumed to be okay to receive a token for
example.com from mumblefratz.example. The server does its validation as
normal. If the token is bad, then the validation will fail and possibly
a stateless retry follows to validate the client's source address.
Otherwise, if the token is valid for the client's source address, then
the server proceeds with the cryptographic handshake.
However, if the number of unrequited connections which had presented an
valid token from mumblefratz.example exceeds a defined threshold value,
then the server will revoke its trust in tokens issued by
mumblefratz.example.

> I must reiterate my statement that I don't think this should in scope
> for v1 at all.
>
> regards,
>
> Ted

---

From: Ian Swett <[email-masked]>
Date: Fri, 12 Apr 2019 19:36:07 -0400

I appreciate your work and this may be valuable in some use cases, but I
also agree with Ted's concerns and I think it's clearly out of scope for
QUIC v1.