Re: Fwd: New Version Notification for draft-kazuho-quic-address-bound-token-00.txt

["Martin Thomson" <[e-mail]>]

On Thu, Apr 4, 2019, at 18:33, Kazuho Oku wrote:
> > We probably need a slightly larger security analysis. What if a service part of a farm issued such a token without coordinating with the other services that use the same address? Could that be a form of DOS?
> 
> Would you mind elaborating about the scenario a bit more? I ask this
> because I am not sure if that is a practical attack. Assuming that it
> is about an attacker running on the same server tuple, why can't the
> attacker just send packets by itself? I might also point out that
> section 8.1.3 of the transport draft [1] prevents such attacks from
> being run.

I don't think that this is a particularly important consideration.  Servers make their own determination about whether clients present a risk of denial of service.  If, as the proposed mechanism proves, the server has recently communicated with the client on the same address, the risk of DoS exposure might reasonably be discounted.

This isn't the only consideration here though.  When we were discussing the use of resumption tickets across different connections, I pointed out that there is no harm in using a ticket with any connection.  Tokens aren't significantly different in this regard - a server still needs to treat them with suspicion.  But linkability concerns might cause clients to avoid use of a token:

1. When you use a token, you can't use it again (or you link any sessions that use the same token).
2. When you use a token, you link that use to the source of the token.

The first is what motivates having a clear signal from the server about the scope over which the token is usable.  Otherwise, the client might waste a token on a connection attempt that was never able to use the token.

Whether or not the second will determine use of the token is largely a question of client policy.  There is some advice we can offer, but ultimately clients will make their own determination.  For instance, it might be reasonable to use a token if the connection is being made in response to resolving a URL that was provided by the first server.  But there are numerous constraints on connection establishment that might alter any determination.

Anything we might consider publishing needs some treatment of these considerations.