Re: Privacy holes (was: Re: Getting to consensus on packet number encryption)

[Kazuho Oku <[e-mail]>]

2018-04-06 3:21 GMT+09:00 Lubashev, Igor <[e-mail]>:

>
>    - It would not, *if* the stateless load balancer can AES-decrypt the
>    packet (using the key derived from the packet header) to see if the packet
>    is in fact a initial packet.
>
>
>
> Would not it need to first decide that the CID in the packet is unknown
> (which means stateful)?  It would need to do some integrity check on CID,
> which would require a large nonce to avoid accidentally classifying a
> random CID as valid, because the cost of this mistake can be very large for
> the client (see below).
>

AEAD tag that is used for checking if a packet is legitimate as a initial
packet is currently 16 octets. That would not change. I believe that it
would be enough to avoid 1-RTT packets being misclassified as handshake
packets.


>
>
>    - Or another way of solving the issue will be to always route the
>    packet based on CID, then forward the packet between the endpoints behind
>    the load balancer.
>
>
>
> This would not really work for a global load balancer – the one capable of
> forwarding across a continent to a different anycast pop (due to client’s
> change in attachment point or BGP reconvergence).
>

Agreed.


>
>
>
>
>
>
> *From:* Kazuho Oku [mailto:[e-mail]]
> *Sent:* Thursday, April 05, 2018 2:09 PM
> *To:* Lubashev, Igor <[e-mail]>
> *Cc:* Mikkel Fahnøe Jørgensen <[e-mail]>; Mike Bishop <
> [e-mail]>; Christian Huitema <[e-mail]>; IETF QUIC
> WG <[e-mail]>; Mirja Kühlewind <[e-mail]>;
> Frederick Kautz <[e-mail]>
> *Subject:* Re: Privacy holes (was: Re: Getting to consensus on packet
> number encryption)
>
>
>
>
>
>
>
> 2018-04-06 2:59 GMT+09:00 Lubashev, Igor <[e-mail]>:
>
>
>    - I'd prefer making handshake packets indistinguishable from short
>    header packets. In essence, you move the flags of the long header inside
>    the AEAD-protected area. An endpoint that receives a packet carrying a CID
>    that does not belong to any known connection trial-decrypts the packet as a
>    initial packet and handles it as a connection initiation, or sends a
>    stateful reset if the trial-decryption fails.
>
> This change would wreck stateless load balancers that rely on being able
> to distinguish CI packets (and route them based on IPs) from other packets
> (and route them based on CID).
>
>
>
> It would not, *if* the stateless load balancer can AES-decrypt the packet
> (using the key derived from the packet header) to see if the packet is in
> fact a initial packet. Or another way of solving the issue will be to
> always route the packet based on CID, then forward the packet between the
> endpoints behind the load balancer.
>
>
>
> I agree that it would be a no-deal for stateless load balancers that are
> incapable of doing such things.
>
>
>
>
>
> - Igor
>
>
>
> *From:* Mikkel Fahnøe Jørgensen [mailto:[e-mail]]
> *Sent:* Thursday, April 05, 2018 1:31 PM
> *To:* Mike Bishop <[e-mail]>; Christian Huitema <
> [e-mail]>; Kazuho Oku <[e-mail]>
> *Cc:* IETF QUIC WG <[e-mail]>; Mirja Kühlewind <
> [e-mail]>; Frederick Kautz <[e-mail]>
> *Subject:* RE: Privacy holes (was: Re: Getting to consensus on packet
> number encryption)
>
>
>
> Hi
>
>
>
> On 5 April 2018 at 19.27.24, Mike Bishop ([e-mail]) wrote:
>
>  An endpoint that receives a packet carrying a CID that does not belong
> to any known connection trial-decrypts the packet as a initial packet and
> handles it as a connection initiation, or sends a stateful reset if the
> trial-decryption fails.
>
> I can see hiding things may be a good thing, but having to trial decrypt
> all unknown packets as potentially creating a huge load, unless you combine
> it with my proposal to add a checksum to the encrypted packet number so you
> only need one crypto block on average to reject random packet content.
>
> It won’t solve all DDoS, but it will help. Forcing trial decryption fo the
> full packet makes me a bit anxious.
>
>
>
> Mikkel
>
>
>
>
>
>
>
> --
>
> Kazuho Oku
>



-- 
Kazuho Oku