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

[Kazuho Oku <[e-mail]>]

2018-04-06 3:09 GMT+09:00 Kazuho Oku <[e-mail]>:

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

PS. Note that the purpose of AES-encrypting the handshake packets is purely
for obfuscation. It might be worth considering changing it to some
snake-oil scrambling scheme if it helps stateless load balancer adopt the
proposed scheme.


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