Subject: Re: Fast Address Validation - about

From: "Qing An" <[email-masked]>
Date: Fri, 01 Nov 2019 20:36:29 +0800

If so, for the first connection between client and server, server can choose to eliminate the use of Retry packet for token delivery, and rely on handshake encryption layer to prove return routability.  In addition, New_Token frame is used by server, via i.e. the Initial packet, to provide the client with an address validation token that can be used to validate future connections.

It can enhance the experience in client side for the first connection establishment.

I submitted the draft, https://datatracker.ietf.org/doc/draft-an-fast-address-validation/

Qing

------------------------------------------------------------------
From:Mike Bishop <[email-masked]>
Send Time:2019年11月1日(星期五) 00:06
To:安勍(莳逸) <[email-masked]>; quic <[email-masked]>; jri.ietf <[email-masked]>; mt <[email-masked]>; mikkelfj <[email-masked]>
Subject:RE: Fast Address Validation - about

As Martin pointed out in the e-mail you replied to, if the server is willing to maintain state, any packet at the Handshake encryption layer proves return routability.  There seems to be no need for a separate address validation mechanism if the server is willing to proceed with the handshake.
From: QUIC <[email-masked]> On Behalf Of  Qing An
Sent: Thursday, October 31, 2019 8:56 AM
To: quic <[email-masked]>; jri.ietf <[email-masked]>; mt <[email-masked]>; mikkelfj <[email-masked]>
Subject: Re: Fast Address Validation - about

To clarify, the proposal is not to replace the existing Retry-based validation, but to provide another option for server to do the client validation.

I understand that in server side, exchanging the token at the Handshake encryption level will make the server start to maintain handshake states. But in client side, it can accelerate the connection establishment from client to server.

And it is the server's decision whether to exchange token in Retry or in Handshake. If server chooses to accept the cost brought by token exchanging in Handshake, it will bring more enhanced experience in client side.

BR,
Qing

------------------------------------------------------------------
From:Martin Thomson <[email-masked]>
Send Time:2019年10月31日(星期四) 06:07
To:quic <[email-masked]>
Subject:Re: Fast Address Validation - about

Also note that exchange of Handshake packets provides proof of return routeability via the use of the encryption keys, so there is no need to exchange tokens at that level.

 On Thu, Oct 31, 2019, at 03:29, Mike Bishop wrote:
 >  
 > The advantage of using Retry, however, is that the server is able to 
 > keep minimal (if any) state about the client. Exchanging the token at 
 > the Handshake encryption level means the server is already doing work 
 > and maintaining state in order to process the handshake, which is 
 > exactly what the server is trying to avoid.
 > 
 > 
 > *From:* QUIC <[email-masked]> *On Behalf Of * Qing An
 > *Sent:* Wednesday, October 30, 2019 9:41 AM
 > *To:* quic <[email-masked]>; jri.ietf <[email-masked]>; mt 
 > <[email-masked]>
 > *Cc:* 刘大鹏(鹏成) <[email-masked]>
 > *Subject:* Fast Address Validation - about
 > 
 > 
 > 
 > 
 > Hi Martin, Jana, 
 > 
 > I read through https://www.ietf.org/id/draft-ietf-quic-transport-23.txt 
 > and have a few comments and ideas to discuss.
 > 
 > 
 > [QUIC-Trans] defines a token based scheme to facilitate address 
 > validation of a client. The token MUST be covered by integrity 
 > protection against modification or falsification by clients. The server 
 > remembers the value it sends to clients and validates the token sent 
 > back from a client. In its design, Retry packet is used to deliver the 
 > token to a client which address has not yet been validated. It voids 
 > the first transmission of the Initial packet sent by the client, and 
 > triggers a second Initial packet to be sent with the token. The 
 > exchange of token will cause longer connection establishment delay for 
 > a client.
 > 
 > 
 > To improve the efficiency of address validation during handshake, one 
 > idea is that the same token can be exchanged via a different container 
 > i.e. the Handshake packet, that eliminates the use of Retry packet for 
 > token delivery. 
 > 
 > 
 > I am working on the complete draft and will submit it by Friday. Before 
 > that, hope this can be discussed in email first.
 > 
 > 
 > BR,
 > 
 > Qing An
 >

---

From: Marten Seemann <[email-masked]>
Date: Fri, 1 Nov 2019 19:53:51 +0700

I don't see any enhanced client experience, since the handshake takes
exactly the same number of round trips with your proposal as with the
current version of the QUIC draft.
Sending NEW_TOKEN in Initial packets provides no benefit over sending it in
1-RTT packets, but comes with worse privacy properties, since Initial
packets are not encrypted and can therefore be read by on-path observers.

On Fri, Nov 1, 2019 at 7:37 PM Qing An <[email-masked]> wrote:

>
> If so, for the first connection between client and server, server can
> choose to eliminate the use of Retry packet for token delivery, and
> rely on handshake encryption layer to prove return routability.
> In addition, New_Token frame is used by
> server, via i.e. the Initial packet, to provide the client with an
> address validation token that can be used to validate future connections.
>
> I submitted the draft,
> https://datatracker.ietf.org/doc/draft-an-fast-address-validation/
>
> Qing
>
>
>
> To:安勍(莳逸) <[email-masked]>; quic <[email-masked]>; jri.ietf <
> [email-masked]>; mt <[email-masked]>; mikkelfj <[email-masked]>
> As Martin pointed out in the e-mail you replied to, if the server is
> willing to maintain state, any packet at the Handshake encryption layer
> proves return routability.  There seems to be no need for a separate
> address validation mechanism if the server is willing to proceed with the
> handshake.
>
>
>
> *Sent:* Thursday, October 31, 2019 8:56 AM
> *To:* quic <[email-masked]>; jri.ietf <[email-masked]>; mt <
> [email-masked]>; mikkelfj <[email-masked]>
> *Subject:* Re: Fast Address Validation - about
>
>
>
>
>
>
>
> To clarify, the proposal is not to replace the existing Retry-based
> validation, but to provide another option for server to do the client
> validation.
>
>
>
> I understand that in server side, exchanging the token at the Handshake encryption level
> will make the server start to maintain handshake states. But in client
> side, it can accelerate the connection establishment from client to server.
>
>
>
> And it is the server's decision whether to exchange token in Retry or in
> Handshake. If server chooses to accept the cost brought by token exchanging
> in Handshake, it will bring more enhanced experience in client side.
>
>
>
>
>
> BR,
>
> Qing
>
>
>
>
>

---

From: Töma Gavrichenkov <[email-masked]>
Date: Fri, 1 Nov 2019 16:00:39 +0300

Peace,

On Wed, Oct 30, 2019, 4:41 PM Qing An <[email-masked]> wrote:

> [QUIC-Trans] defines a token based scheme
> to facilitate address validation of a client. The token MUST be covered by
> integrity protection against modification or falsification by clients. The
> server remembers the value it sends to clients and validates the token sent
> back from a client.
>

About the only use case for the client address validation I can think of is
the protection against Hello packet floods exhausting the resources
(including memory) on the server.

In this case keeping any state for connections coming from potentially
spoofed addresses on the server compromises the very concept of flood
protection.  All the state must be kept in the Retry packet and promptly
signaled back by the client.

The speed-up brought in by keeping the state is probably negligible (TODO:
actual measurements) while with a today's average 300Mpps packet flood
hardly any state could be kept for any reasonable period of time.

--
Töma

---

From: "Qing An" <[email-masked]>
Date: Fri, 01 Nov 2019 21:26:17 +0800

I believe this can save 1-RTT.

As for the privacy risk, new_token frame can be delivered via handshake

------------------------------------------------------------------
From:Marten Seemann <[email-masked]>
Send Time:2019年11月1日(星期五) 20:54
To:安勍(莳逸) <[email-masked]>
Cc:QUIC <[email-masked]>; quic <[email-masked]>; jri.ietf <[email-masked]>; mt <[email-masked]>; mikkelfj <[email-masked]>; 刘大鹏(鹏成) <[email-masked]>
Subject:Re: Fast Address Validation - about

I don't see any enhanced client experience, since the handshake takes exactly the same number of round trips with your proposal as with the current version of the QUIC draft.
Sending NEW_TOKEN in Initial packets provides no benefit over sending it in 1-RTT packets, but comes with worse privacy properties, since Initial packets are not encrypted and can therefore be read by on-path observers.

Qing

BR,
Qing

---

From: "Qing An" <[email-masked]>
Date: Fri, 01 Nov 2019 21:26:24 +0800

Right, client address validation can provide protection against floods, but today's server often has other approaches to handle floods. In this case, IMHO it is reasonable to make it possible for server to choose whether or not to use Retry for client address validation

Peace,

On Wed, Oct 30, 2019, 4:41 PM Qing An <[email-masked]> wrote:
[QUIC-Trans] defines a token based scheme to facilitate address validation of a client. The token MUST be covered by integrity protection against modification or falsification by clients. The server remembers the value it sends to clients and validates the token sent back from a client.

About the only use case for the client address validation I can think of is the protection against Hello packet floods exhausting the resources (including memory) on the server.

In this case keeping any state for connections coming from potentially spoofed addresses on the server compromises the very concept of flood protection.  All the state must be kept in the Retry packet and promptly signaled back by the client.

The speed-up brought in by keeping the state is probably negligible (TODO: actual measurements) while with a today's average 300Mpps packet flood hardly any state could be kept for any reasonable period of time.

--
Töma

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 1 Nov 2019 06:37:38 -0700

You only save a roundtrip because you do not send a Retry.

If you choose not to send a Retry, the client eventually gets validated
anyway because otherwise the handshake could not complete. Therefore a
Retry token is not needed if you go down that path. In this case the RTT
overhead with fast address validation is the same as ordinary QUIC 1-RTT
handshake.

On the other hand, in the case where Retry is needed, the fast address
validation approach does not solve the problem which is one of 1) defer
handshake processing and server state until after the address is verified,
or 2) redirect the client to another server through a change in
ConnectionID.

On 1 November 2019 at 14.26.24, Qing An ([email-masked]) wrote:

------------------------------------------------------------------
From:Marten Seemann <[email-masked]>
Send Time:2019年11月1日(星期五) 20:54
To:安勍(莳逸) <[email-masked]>
Cc:QUIC <[email-masked]>; quic <[email-masked]>; jri.ietf <
[email-masked]>; mt <[email-masked]>; mikkelfj <[email-masked]>;
刘大鹏(鹏成) <[email-masked]>
Subject:Re: Fast Address Validation - about

It can enhance the experience in client side for the first connection
establishment.

I submitted the draft,

Qing

*From:* QUIC <[email-masked]> *On Behalf Of* Qing An

I understand that in server side, exchanging the token at the
Handshake encryption level
will make the server start to maintain handshake states. But in client
side, it can accelerate the connection establishment from client to server.

BR,

Qing

To:quic <[email-masked]>

Also note that exchange of Handshake packets provides proof of return
routeability via the use of the encryption keys, so there is no need
to exchange tokens at that level.

---

From: Töma Gavrichenkov <[email-masked]>
Date: Fri, 1 Nov 2019 17:00:54 +0300

On Fri, Nov 1, 2019, 4:26 PM Qing An <[email-masked]> wrote:

> Right, client address validation can provide protection against floods,
> but today's server often has other approaches to handle floods.
>

Speaking of Hello flood (and SYN flood), what particular approaches do you
have in mind?

--
Töma

---

From: "Qing An" <[email-masked]>
Date: Fri, 01 Nov 2019 22:47:13 +0800

For initial flood, there are approaches like source address statistics and speed limitation.

 ------------------Original Mail ------------------
Sender:Töma Gavrichenkov <[email-masked]>
Send Date:Fri Nov 1 22:01:08 2019
Recipients:Qing An <[email-masked]>
CC:IETF QUIC WG <[email-masked]>, jri.ietf <[email-masked]>, mt <[email-masked]>, 刘大鹏(鹏成) <[email-masked]>
Subject:Re: Fast Address Validation - about

On Fri, Nov 1, 2019, 4:26 PM Qing An <[email-masked]> wrote:
Right, client address validation can provide protection against floods, but today's server often has other approaches to handle floods.

Speaking of Hello flood (and SYN flood), what particular approaches do you have in mind?

--
Töma

---

From: "Qing An" <[email-masked]>
Date: Fri, 01 Nov 2019 22:55:03 +0800

Again, the fast address validation is to provide another option for server, not to drop the Retry approach.

I think if choose not to send a Retry, it is necessary to define how to deliver token from server to client. In this case,  via new_token frame in handshake can be an approach.

 ------------------Original Mail ------------------
Sender:Mikkel Fahnøe Jørgensen <[email-masked]>
Send Date:Fri Nov 1 21:37:42 2019
Recipients:Qing An <[email-masked]>, Marten Seemann <[email-masked]>
CC:jri.ietf <[email-masked]>, QUIC <[email-masked]>, quic <[email-masked]>, mt <[email-masked]>, 刘大鹏(鹏成) <[email-masked]>
Subject:Re: Fast Address Validation - about

If you choose not to send a Retry, the client eventually gets validated anyway because otherwise the handshake could not complete. Therefore a Retry token is not needed if you go down that path. In this case the RTT overhead with fast address validation is the same as ordinary QUIC 1-RTT handshake.

On the other hand, in the case where Retry is needed, the fast address validation approach does not solve the problem which is one of 1) defer handshake processing and server state until after the address is verified, or 2) redirect the client to another server through a change in ConnectionID.

Qing

  

 BR, 
 Qing

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 1 Nov 2019 08:19:26 -0700

But what do you need to the token for in this case? The token is to prove
that you previously spoken to the server. But the TLS handshake provides
the same proof (but cannot redirect and must carry state). Any additional
information the token might carry is only interesting in Initial packets
where the connection can be stopped early or (in ongoing work) to encrypt
the initial packet. That is not relevant during handshake. The Diffie
Helman key exchange takes care of all this. Since you proposal also cannot
redirect and must carry state, I don’t see the purpose. I do agree you can
deliver that token, but since it is not obvious what the token is needed
for, the purpose is unclear.

You appear to assume that address validation only happens if you have a
Retry token, bu that is not correct, it just happens with less server
resources.

On 1 November 2019 at 15.55.09, Qing An ([email-masked]) wrote:

Again, the fast address validation is to provide another option for server,
not to drop the Retry approach.

I think if choose not to send a Retry, it is necessary to define how to
deliver token from server to client. In this case,  via new_token frame in
handshake can be an approach.

------------------Original Mail ------------------
Sender:Mikkel Fahnøe Jørgensen <[email-masked]>
Send Date:Fri Nov 1 21:37:42 2019
Recipients:Qing An <[email-masked]>, Marten Seemann <
[email-masked]>
CC:jri.ietf <[email-masked]>, QUIC <[email-masked]>, quic <
[email-masked]>, mt <[email-masked]>, 刘大鹏(鹏成) <[email-masked]>
Subject:Re: Fast Address Validation - about

> Sending NEW_TOKEN in Initial packets provides no benefit over sending it
> in 1-RTT packets, but comes with worse privacy properties, since Initial

---

From: Töma Gavrichenkov <[email-masked]>
Date: Fri, 1 Nov 2019 19:35:05 +0300

On Fri, Nov 1, 2019 at 5:47 PM Qing An <[email-masked]> wrote:
> For initial flood, there are approaches like
> source address statistics

This is a very rough and biased method at best.  Generally (which
would be IMNSHO 98% of the cases), the statistics about past events
doesn't tell you with an accuracy anywhere close to being reliable if
this particular new packet could be from spoofed source or not.

E.g. an attacker who would generate spoofed packets from the typical
source addresses for your type of business in your country (e.g.
popular cellular NAT pools for news sites) would circumvent that check
easily.  With the overwhelming majority of HTTPS resources there's
hardly any point in giving the latter a shot.

> and speed limitation.

And you'll be limiting the speed for legitimate clients as well in the
above example (and many other scenarios).  This is a nice way to
amplify the effects of an attack, much less to handle those.

***

With the greatest of respect, speaking more broadly, please take into
account that a good engineering practice (no matter if it's Internet
engineering or whatever) must not rely on the assumption that
something which is perceived as typical would always happen, and
something perceived as non-typical would never occur just because it
has to date never occurred in the past.

The example commonly seen in university books on engineering would be
e.g. the Oppau explosion — caused by the factory workers tearing
through ammonium with dynamite, just because ammonium has never
detonated during that operation before and was thus believed to be
unlikely to explode in future.  An example more close to the content
of this WG would be middlebox vendors hard-coding "typical" protocol
behaviour into their products (causing transport protocol ossification
which the WG spends I believe no less than 50% of time fighting
against) just because the said vendors do not appear to see the
standard but non-typical behaviour in their sample network dumps.

Both approaches you propose are vulnerable to a few simple
circumvention techniques, and while I totally accept that probably
you've never seen those techniques applied against your network, they
are quite extensively documented.  Therefore it's hard to see, at
least for me, why the IETF should account for the flawed mitigation
approaches during the transport protocol design.

--
Töma

---

From: Töma Gavrichenkov <[email-masked]>
Date: Fri, 1 Nov 2019 20:34:14 +0300

Peace,

A quick review goes below:

> The server remembers the value it sends to
> clients and validates the token sent back from a client.

As discussed before, this description of the Retry mechanism is
inaccurate to the point it defeats its very purpose.

> Address validation is used by QUIC to avoid being used for a traffic
> amplification attack.

This is also inaccurate; the lower bound for the Initial packet size
prevents amplification.  Retry token is there to mitigate Initial
packet floods.  Neither prevent trivial reflection, if you will.

> If server chooses to
> accept the cost brought by token exchanging in Handshake
> [..]
> Adding token field to Handshake packet does not add new security
> concerns.

At least one security concern I see here is what data the server is
expected to derive its decision to accept the cost from.

E.g. with the aforementioned 300 Mpps Initial packet flood, what is
the approximate cost of keeping the state, per second?  If you would
just be storing 16 octets of an IPv6 address plus 2 octets of the
client's ephemeral port for any Rx packet, that'd be more than 5
Gbytes of RAM consumed *per second* of the attack, not including the
pointers, hashes etc.  Next, I haven't exactly done the math, but I
think that the draft implies that the state kept would be hardly less
than an order of magnitude bigger than that.  Also, the cost of
processing every spoofed packet through the whole handshake pipeline,
and so on.  I believe this is where the authors need to come up with
benchmarks and implementation hints on garbage collection methods etc.

I know the amount of RAM available is destined to grow but the floods
are not expected to shrink any time soon just as well.

--
Töma

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 1 Nov 2019 14:36:16 -0700

Qing,

Thank you for writing up the draft.

As several others have noted, the RTT spent with Retry is not unnecessary,
it is fundamental to the purpose of Retry. If the server is willing to
maintain state, it doesn't need to send a Retry packet at all. If the
server is willing to maintain state and therefore does not send a Retry at
all, what is the value of your proposal?

- jana

---

From: "Qing An" <[email-masked]>
Date: Sat, 02 Nov 2019 06:05:51 +0800

Thanks for the elaborate explanation.

The security & privacy approaches I listed are just some examples. In today’s network, it would be hard to defend those attacks you mentioned just relying one specific approach. How to prevent those attacks may be a broader story, not just specific to QUIC.

And based on the my company’s deployment experience, forcing to use Retry for address validation does cause some experience flaw in client side. Therefore, it is recommended to allow an approach that can accelerate the first connection establishment.

Qing

 ------------------Original Mail ------------------
Sender:Töma Gavrichenkov <[email-masked]>
Send Date:Sat Nov 2 01:34:31 2019
Recipients:Qing An <[email-masked]>
CC:QUIC <[email-masked]>, quic <[email-masked]>, jri.ietf <[email-masked]>, mt <[email-masked]>, mikkelfj <[email-masked]>, 刘大鹏(鹏成) <[email-masked]>
Subject:Re: Fast Address Validation - about
Peace,

--
Töma

---

From: "Qing An" <[email-masked]>
Date: Sat, 02 Nov 2019 06:27:56 +0800

Based on discussion, the proposal is for first connection establishment, server chooses to eliminate Retry and rely on handshake. But server can also use New_Token frame via Handshake or Initial to deliver token for future connection.

 ------------------Original Mail ------------------
Sender:Mikkel Fahnøe Jørgensen <[email-masked]>
Send Date:Fri Nov 1 23:19:30 2019
Recipients:Qing An <[email-masked]>, Marten Seemann <[email-masked]>
CC:jri.ietf <[email-masked]>, QUIC <[email-masked]>, quic <[email-masked]>, mt <[email-masked]>, 刘大鹏(鹏成) <[email-masked]>
Subject:Re:Re: Fast Address Validation - about

But what do you need to the token for in this case? The token is to prove that you previously spoken to the server. But the TLS handshake provides the same proof (but cannot redirect and must carry state). Any additional information the token might carry is only interesting in Initial packets where the connection can be stopped early or (in ongoing work) to encrypt the initial packet. That is not relevant during handshake. The Diffie Helman key exchange takes care of all this. Since you proposal also cannot redirect and must carry state, I don’t see the purpose. I do agree you can deliver that token, but since it is not obvious what the token is needed for, the purpose is unclear.

You appear to assume that address validation only happens if you have a Retry token, bu that is not correct, it just happens with less server resources. 
On 1 November 2019 at 15.55.09, Qing An ([email-masked]) wrote: 

------------------Original Mail ------------------

Qing

  

 BR, 
 Qing

---

From: Christian Huitema <[email-masked]>
Date: Fri, 1 Nov 2019 15:41:12 -0700

On 11/1/2019 3:27 PM, Qing An wrote:
> Based on discussion, the proposal is for first connection
> establishment, server chooses to eliminate Retry and rely on
> handshake. But server can also use New_Token frame via Handshake or
> Initial to deliver token for future connection.

We have discussed before that sending a token in the Initial packet is
bad for privacy and also for security, because the initial packets are
encrypted with a well known key. The current specification allows you to
send the New_Token frame in 1-RTT, whether or not the connection was
preceded by a Retry attempt.

There would be some disadvantage to sending the frame in an Handshake
packet. Many implementations stop processing the content of handshake
packets once the handshake is complete. The crypto frames would be all
received before the New_Token frame, and the new token frame would then
be ignored.

It seems simpler to keep the current specification, and transmit the
New_Token frame in 1-RTT.

-- Christian Huitema

---

From: "Qing An" <[email-masked]>
Date: Sat, 02 Nov 2019 07:03:51 +0800

The proposal is to, if server chooses not to send a Retry, for first connection, define how to use new_token frame to deliver token to client for future connection.

 ------------------Original Mail ------------------
Sender:Jana Iyengar <[email-masked]>
Send Date:Sat Nov 2 05:36:30 2019
Recipients:Qing An <[email-masked]>
CC:quic <[email-masked]>, 刘大鹏(鹏成) <[email-masked]>
Subject:Re: Fast Address Validation - about

Qing,

As several others have noted, the RTT spent with Retry is not unnecessary, it is fundamental to the purpose of Retry. If the server is willing to maintain state, it doesn't need to send a Retry packet at all. If the server is willing to maintain state and therefore does not send a Retry at all, what is the value of your proposal?

- jana

 --
 Töma

---

From: Christian Huitema <[email-masked]>
Date: Fri, 1 Nov 2019 20:17:09 -0700

On 11/1/2019 4:03 PM, Qing An wrote:
>
> The proposal is to, if server chooses not to send a Retry, for first
> connection, define how to use new_token frame to deliver token to
> client for future connection.

This is already supported. Just send a "NEW TOKEN" frame in an 1 RTT
packet, once the handshake is complete. The clients should remember
that, and use it on their next connections.

-- Christian Huitema

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 1 Nov 2019 23:51:07 -0700

I can see how a token in the initial packet can speed up a second
connection because you can drop the handshake if you do not like the token.

But isn’t that exactly what 0-RTT connections / tokens are supposed to do?

And for delivering new tokens for future use it does not really matter if
it is delivered in the handshake from a performance perspective because 1)
you are likely to continue doing more work anyway, and 2) if not, you still
need to confirm the handshake before trusting the connection, and 3)
coalescing 1-RTT packets are not usually slower than sending in handshake.

>From a security perspective there are other concerns as Christian has
discussed.

Delivering Retry tokens for future use (as you mention your next mail) may
be problematic due to life time concerns. 0-RTT tokens are expected to live
longer than Retry and Retry tokens and the Connection ID associated with
it, reflects the current server farms load such that new connections can
redirect immediately, not sometime later.

On 1 November 2019 at 23.28.03, Qing An ([email-masked]) wrote:

Based on discussion, the proposal is for first connection establishment,
server chooses to eliminate Retry and rely on handshake. But server can
also use New_Token frame via Handshake or Initial to deliver token for
future connection.

------------------Original Mail ------------------

>> [email-masked]>; mt <[email-masked]>; mikkelfj <[email-masked]
>> >

---

From: Christian Huitema <[email-masked]>
Date: Sat, 2 Nov 2019 00:26:40 -0700

There may be scenarios in which having address proof tokens would help. For example, provision the token during normal operation but only enforce them when under attack. I assume that's what Qing An has in mind. But it is safer and more reliable to provision the tokens using 1rtt packets, after the handshake is verified.

-- Christian Huitema 

> On Nov 1, 2019, at 11:51 PM, Mikkel Fahnøe Jørgensen <[email-masked]> wrote:
> 
> 
> I can see how a token in the initial packet can speed up a second connection because you can drop the handshake if you do not like the token.
> 
> And for delivering new tokens for future use it does not really matter if it is delivered in the handshake from a performance perspective because 1) you are likely to continue doing more work anyway, and 2) if not, you still need to confirm the handshake before trusting the connection, and 3) coalescing 1-RTT packets are not usually slower than sending in handshake.
> 
> From a security perspective there are other concerns as Christian has discussed.
> 
> Delivering Retry tokens for future use (as you mention your next mail) may be problematic due to life time concerns. 0-RTT tokens are expected to live longer than Retry and Retry tokens and the Connection ID associated with it, reflects the current server farms load such that new connections can redirect immediately, not sometime later.
>