Re: Request forgery in QUIC

[Martin Thomson <[e-mail]>]

Hi Igor.

On Fri, Aug 14, 2020, at 01:06, Lubashev, Igor wrote:
>   * We can recommend clients to use NEW_TOKEN tokens only when it 
> reconnects to an address that is previously known.
>  
> 
> This would mostly defeat the purpose of NEW_TOKEN tokens in the context 
> of DNS-mapped CDNs.  Clients would quickly learn to either not to 
> follow this recommendation, or to keep an extensive history of 
> addresses and guess at subnets they come from, or to risk lower 
> handshake performance.

The PR tries to address this in stages.  It first says that clients MUST NOT send a token if the server address changes, but then it goes on to list some exceptions.  The first is allowing clients to treat "nearby" addresses as equivalent, for some definition of nearby.  The second is allowing the original address and any validated preferred address to be equivalent.

This might not work for you here.  In particular, if you believe that you can share tokens between servers in dramatically different networks, then you those tokens won't be carried between those server instances.  I can think of a couple of cases that are at least plausible:

* if you have an in-ISP CDN node and one in the cloud they will likely have very different IP addresses (assuming that you don't use anycast) so the client will believe them to be different and not transfer tokens from one to the other.

* if the same name is served by multiple CDNs and somehow they are able to consume tokens from each other, then clients wont transfer tokens.

No matter the circumstances, the loss is not serious.  Tokens from NEW_TOKEN are always opportunistic and provide pretty weak address validation anyway.  They might lift the 3x limit, but that mostly only helps you get a large certificate out.

Servers can't rely on getting these tokens anyway, which is why I think this is a reasonable countermeasure.

> The best recommendation is watching for a notional security escalation 
> between “globally routable IP space” -> “RFC1918/unique-local IP space” 
> -> “link-local” -> “loopback”.  

The PR addresses this point specifically under a heading for generic countermeasures.  I can see clients being cautious about these "escalations", but I don't think that anything but the last can be uniformly blocked.  And even that might need exceptions.  If you have an argument to support stronger protection, that would be good.  But I think that dropping NEW_TOKEN tokens is a far safer choice.  

BTW, under the pull request, clients are free to treat all globally routeable space as equivalent for the purposes of token reuse.  However, I don't think that is at all advisable.  On the contrary, I know for certain that it is unsafe.  Maybe this doesn't happen much any more - it certainly shouldn't - but at a previous employer we had unprotected services that used public IP addresses (the company used a class A IPv4 subnet for its services, which might give you a clue...)