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

[Frederick Kautz <[e-mail]>]

Maybe there could be some form of unencrypted header which load balancers
could use to land it to the correct location? This id could be set by the
server after a successful negotiation, and would be shared across all
connections to that same server. It can be used to ensure that the same
server internally always handles the given connection while attempting to
keep linkability low.

On Thu, Apr 5, 2018 at 11:35 AM, Kazuho Oku <[e-mail]> wrote:

>
>
> 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
>