Re: Packet number encryption

[Ian Swett <[e-mail]>]

On Fri, Feb 9, 2018 at 8:51 AM, Eric Rescorla <[e-mail]> wrote:

>
>
> On Thu, Feb 8, 2018 at 9:40 PM, Praveen Balasubramanian <
> [e-mail]> wrote:
>
>> Actually taking a step back what if we don’t we overloaded packet number
>> as the nonce?
>>
>>
>>
>> Can we:
>>
>>    1. Put packet number as a separate variable length field in the
>>    encrypted portion of the header. This allows for growth beyond 64 bits in
>>    future and completely avoids ossification. For short lived flows variable
>>    length encoding leads to minimal space overhead.
>>    2. Put a separate plaintext nonce which starts out as a secure random
>>    number and monotonically increases as short random jumps (every packet or
>>    every few packets) and could then rollover. This will prevent linkability
>>    and scales to multi-path as well. No major compute overhead. We can also
>>    make the nonce optional for crypto algorithms that do not need a nonce
>>    saving more space.
>>
>>
> I'm not sure how to do #2 safely and efficiently. The primary concern is
> that short random jumps don't actually prevent linkability because the high
> order bits don't change and long random jumps are effectively randomly
> sampling out of the nonce space, and you start to run into birthday
> problems. Additionally, the cheapest PRNGs are basically ciphers in counter
> mode, so at best you're going to get a small amount of overhead reduction
> by getting multiple jump computations out of a single block, though if you
> use 96-bit jumps, you only get 25% savings...
>
> -Ekr
>
>
>
> Some MSB of the nonce could be used for signaling reorder to the network
>> if needed. I don’t have the historical context for overloading of PN as the
>> nonce so pardon me if un-overloading option was discussed and ruled out
>> before.
>>
>>
>>
>> *From:* QUIC [mailto:[e-mail]] *On Behalf Of *Praveen
>> Balasubramanian
>> *Sent:* Thursday, February 8, 2018 5:51 PM
>> *To:* huitema <[e-mail]>; [e-mail]
>> *Subject:* RE: Packet number encryption
>>
>>
>>
>> >> and using separate packet sequences for each path
>>
>> This alone prevents linkability right?
>>
>>
>>
>> >> The packet number on each path will start at 1 (or maybe 0 ;-).
>>
>> Is supporting multiple paths at the same time a goal? If yes, then yes
>> all paths will need to have separate tracking and ACK state and congestion
>> control etc. I thought this is not part of V1 RFC. If its just one
>> additional path for connection migration scenario then all you need is a
>> (random) jump to a offset in packet number space for the new path so that
>> the few packets in the old path can continue for a little bit. This works
>> with just one ACK space so no implementation complexity.
>>
>>
>>
>> >> 2) Or, leaving the packet number in the clear but using different
>> encryption contexts for each path, and using separate packet sequences for
>> each path.
>> In addition if the value in the clear was obfuscated with an XOR
>> transform it will help prevent ossification. The obfuscation is not meant
>> to guard against later analysis that reveals the packet numbers - why do we
>> care about that. It is meant to grease the space and not make the numbers
>> serial so middleboxes cannot assume ordering etc.
>>
>>
>>
>> All said if I am alone in being concerned about the perf hit then I’d say
>> go on with option 1.
>>
>>
>>
>> *From:* QUIC [mailto:[e-mail] <[e-mail]>] *On
>> Behalf Of *Christian Huitema
>> *Sent:* Thursday, February 8, 2018 3:54 PM
>> *To:* [e-mail]
>> *Subject:* Re: Packet number encryption
>>
>>
>>
>> On 2/8/2018 1:13 PM, Mike Bishop wrote:
>>
>> #2 won’t work.  The packet number is an input to the AEAD nonce, so you
>> have to get to the packet number before you can decrypt the payload.  It
>> can’t be based on anything internal to the encrypted packet.
>>
>>
>>
>> In Martin’s proposal, it’s using a combination of the encrypted payload
>> (which requires nothing to access) and some stored state on each endpoint,
>> which requires only the Connection ID to look up.  You want the thing you
>> XOR by to be constantly changing, or it becomes easier to look at sequences
>> of obfuscated packet numbers and start drawing inferences about what the
>> XOR value is.  If overhead is the primary concern, I think there are a
>> couple approaches that might allow you to precompute values and amortize
>> the cost of doing the encryption step.  (At the cost of keeping the table
>> of precomputed values, of course.)
>>
>>
>>
>> I still think Jana’s pushing in the right direction here:  Let’s agree on
>> goals, and then see if we can craft a design that meets those goals.  I
>> hear you saying that low overhead is a goal, which I think we can all agree
>> on.  I also think I hear you saying that 1-1.5% overhead is too high, but
>> it sounds like there’s less agreement on that.  You also raise an
>> interesting point that some clients will care less about linkability
>> because they will never intentionally migrate.
>>
>>
>> I think Victor said it best, "Obfuscation is just encryption done
>> poorly." Either we encrypt, or we don't. But there is no such thing as an
>> obfuscation middle-ground. Obfuscation would just be a speed bump, easily
>> broken. It won't provide privacy, and it won't prevent linkability.
>>
>> As far as I am concerned, there are only two designs that prevent
>> linkability:
>>
>> 1) Martin's PR, in which the packet number is encrypted using sensible
>> crypto;
>>
>> 2) Or, leaving the packet number in the clear but using different
>> encryption contexts for each path, and using separate packet sequences for
>> each path.
>>
> I don't believe the second is necessary if we want to leave the PN in the
clear.  Avoiding nonce reuse is relatively easy.  Avoiding linkability is
more annoying, but doable.

On net, I think encryption may be the best approach, but I don't think not
doing encryption demands the complexity you indicate.


> The second option requires more computation when explicitly setting up a
>> new path. The connection ID would be used as part of the "salt" when
>> deriving connection contexts. The packet number on each path will start at
>> 1 (or maybe 0 ;-). This requires maintaining separate SACK dashboards for
>> each path/Connection-ID, and constraining ACK to be per/path, or
>> alternatively adding a PATH-ACK frame that indicates the path for which
>> packets are acked.
>>
>> The pros and cons of the two options are easy to get:
>>
>> 1) Option 2 does not require the cost of encrypting every packet, thus
>> per packet processing will be maybe 1% faster than option 1.
>>
>> 2) Option 2 requires computing encryption contexts for each path, which
>> is more complex than option 1, but the cost will be amortized over the
>> duration of the path.
>>
>> 3) Option 2 requires more complex data structures and ACK management,
>> thus increasing the chances that something goes wrong.
>>
>> 4) Option 2 does nothing against packet number ossification. The packet
>> number effectively becomes part of the invariants.
>>
>> In short, the only advantage of option 2 is to avoid a single symmetric
>> encryption operation per packet, while making the code significantly more
>> complex, and at the cost of not protecting against PN ossification. The way
>> I see that, there is hardly any debate.
>>
>> -- Christian Huitema
>>
>
>