Usage of Address Validation Tokens and 0-RTT on Chromium-based devices about quic-go HOT 5 CLOSED

Interesting debugging! This does indeed sound like a Quiche issue. Can you post the link to the issue here?

from quic-go.

Correction: 0-RTT works with recent versions of caddy (v2.7.4) and quic-go (>v0.37.5). Sorry for the confusion.
However, while after each successful connection establishment, a NEW_TOKEN frame containing an address validation token is sent, that token is not used inside the initial packet of a subsequent connection, even when 0-RTT packets are sent alongside.

from quic-go.

Sounds like a Chromium bug, right? I’m not sure how Chromium handles tokens, might be worth capturing a packet trace when it connects to google.com or YouTube.

from quic-go.

I thought so too, but was not sure. After a bit of debugging, the issue is clear.

Chromium (or Quiche, more precisely) throws away tokens if they arrive before it gets a crypto frame containing a NewSessionTicket. It works as follows:

• Upon arrival of a NEW_TOKEN frame, the token gets stored alongside its associated server ID (i.e. a combination of host and port) inside a cache that holds TLS sessions.
• When a new session ticket arrives, the session gets added to the cache entry for the associated server
• This new session does not specify the same QUIC transport parameters and is therefore assumed to be related to another, more recent session. The old cache entry (containing the token) gets removed and a new entry without the token is inserted.

I am not quite sure if this behavior is intentional or not. It seems weird though.

quic-go currently always sends the token first:

AFAIK, a client should be able to use tokens independent of the TLS session ticket, therefore I will open an issue in the Quiche project.

from quic-go.

Thanks for opening the issue in Google Quiche! Is there anything left to do on the quic-go side, or should we close this issue?

from quic-go.