Subject: Handshake costs 2-RTT when token validation fail

From: Jiuhai Zhang <[email-masked]>
Date: Fri, 12 Jul 2019 17:45:31 +0800

Can server continue to handshake when token validation fail? Client

may send new token in Handshake packet.

Just like this

Client                                                  Server

   Initial ->

                                                   <- Retry+Token
                                                   <- Handshake

   Handshake+Token->

Is there other solution to avoid 2-RTT?

--------------------

Client                                                  Server

   Initial[0]: CRYPTO[CH] ->

                                                   <- Retry+Token

   Initial+Token[1]: CRYPTO[CH] ->

                                    Initial[0]: CRYPTO[SH] ACK[1]
                          Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
                                    <- 1-RTT[0]: STREAM[1, "..."]

                  Figure 5: Example Handshake with Retry

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 15 Jul 2019 12:27:18 +1000

The reason we have Retry is to force an extra RTT.  This is really only for the case where the server is unable or unwilling to process the Initial without proof that the client is "live".  That is, the client can demonstrate that they are not spoofing their source address.

On Fri, Jul 12, 2019, at 19:45, Jiuhai Zhang wrote:
> Can server continue to handshake when token validation fail? Clientmay 
> send new token in Handshake packet.Just like thisClient                 
>                                  Server
> 
>    Initial ->
> 
>                                                    <- Retry+Token
>                                                    <- Handshake
> 
>    Handshake+Token->
> 
> Is there other solution to avoid 2-RTT?--------------------Client       
>                                            Server
>