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

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

Reconsidering this, thanks to symmetric CID, I think we now have a way to
statelessly determine whether or not a packet is initial without decrypting
it, even if the type field is encrypted.

Initial packets always carry a DCID of 8 octets.

So if you could configure your servers to use DCID of any other size, you
can determine if a packet is initial or not just by checking the size of
DCID.

And assuming that there would be non-neglible amount of servers using DCID
of 8 octets, the size of the field would be unusable as a way to detect if
a packet is initial from the middlebox's point of view.

Igor, Praveen, does the approach alleviate your concern?


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