Subject: RE: Public reset PR

From: "Christian Huitema" <[email-masked]>
Date: Sun, 11 Dec 2016 17:09:06 -0800

On Sunday, November 27, 2016 4:43 PM, Eric Rescorla wrote:

>On Sun, Nov 27, 2016 at 4:35 PM, Christian Huitema <mailto:[email-masked]> wrote:
>> On Sunday, November 27, 2016 12:13 PM, Eric Rescorla wrote:
>>> On Sun, Nov 27, 2016 at 1:36 PM, Christian Huitema <mailto:mailto:[email-masked]> wrote:
>>>> ...
>>>> Responding to Eric: I am not sure that I understand how the second option works
>>>> for the "rebooted server" scenario. Sure, the rebooted server can use a persistent
>>>> secret to compose the magic prefix of the encrypted payload. But what about the
>>>> sequence number? If it is not within the range that the client expect, the packet
>>>> will be dropped before processing the encrypted payload.
>>>
>>> Christian, can you elaborate on this? You are referring to the range of the server's
>>> sequence numbers, right?
>>
>> Yes. If the rebooted server makes up a sequence number for the PR, the packet could 
>> be rejected by sequence number testing prior to the decryption attempt. Also, if a 
>> middlebox keeps track of sequence numbers it will discover that the PR is out of sequence, 
>> which somehow breaks the design goal that "The middlebox cannot distinguish the public 
>> reset from other packets."
>>
>>> If so, it seems like that's fixed by modifying my algorithm to check the prefix as the
>>> first thing on an incoming packet. But maybe I've missed something.
>>
>> That will work for the client, but an overactive middlebox could decide that "this packet 
>> does not look to have the right sequence number" and drop it. I suppose that we could work 
>> around that with a creative use of sequence number compression. Mostly.
>
> Good point. So it's not totally indistinguishable. Ugh.

We now have this proposal in PLUS to augment the public header in QUIC and carry not just the packet sequence number, but also the "last seen number" from the other side. If we have that, then it becomes easy for the rebooted server to set their own sequence number to the packet's received last seen + 1, and the last seen value to the sequence number of the received packet. And then, yes, your proposal would just work. And it would be undistinguishable by middle boxes.

-- Christian Huitema

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Dec 2016 11:08:57 +1100

On 12 December 2016 at 12:09, Christian Huitema <[email-masked]> wrote:
> We now have this proposal in PLUS to augment the public header in QUIC and carry not just the packet sequence number, but also the "last seen number" from the other side.

That only works if you include the entire packet number.  That's a lot
of bits to be sending on every packet.

This discussion makes me wonder if it is possible to encrypt the
packet number.  I think that it's possible.

---

From: Martin Duke <[email-masked]>
Date: Mon, 12 Dec 2016 16:25:26 -0800

If I recall correctly from the way Chromium QUIC crypto works, the packet
number is an input to properly set the IV for decryption. I am far from a
TLS expert, but I believe it introduces diversity into the encryption
between datagrams and is necessary for the sender to explicitly provide.

I think there's a way to do this securely if we accept the expense of PKI
sign/authenticate operations. Any client that thinks it is in
mid-connection with a server, by definition, has its certificate and public
key; therefore, the server could sign a public reset in its private key
with reasonable expectation that it the client can authenticate it.

Sadly, in the other direction only authenticated clients could do the same.

On Mon, Dec 12, 2016 at 4:08 PM, Martin Thomson <[email-masked]>
wrote:

> > We now have this proposal in PLUS to augment the public header in QUIC
> and carry not just the packet sequence number, but also the "last seen
> number" from the other side.
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Dec 2016 11:46:04 +1100

> between datagrams and is necessary for the sender to explicitly provide.

Yes, but the (nascent) idea is that each peer could run the value
through a PRP to recover the actual packet number.

The observation is that the packet number is only (legitimately) used
by an endpoint that also has a decryption key.  So you could do a lot
as long as you were willing to accept a few trade-offs.

It wouldn't require fancy crypto.  It wouldn't be very effective
against a motivated attacker, and it wouldn't prevent spoofing, so
it's not clear how much help it would be.  And you would also have to
burn at least one bit of the (truncated) packet number to even have a
half-plausible story.  But then, the benefits to reducing mucking
around on-path might be worth spending the time.

---

From: Brian Trammell <[email-masked]>
Date: Tue, 13 Dec 2016 11:12:40 +0100

hi Martin, all,

> On 13 Dec 2016, at 01:08, Martin Thomson <[email-masked]> wrote:
> 

That depends on how many bits of the packet and the echo are necessary to (1) support RTT and loss measurement on path and (2) support plausibility checks to re-establish state at middleboxes (the association/confirmation cycle in draft-trammell-plus-statefulness).

The answer to (1) is "not very many"; basically you need to limit the probability of a packet number wraparound through a burst of lost packets. Ian's mentioned 16 bits as a reasonable assumption here.

The answer to (2) may be "not very many" as well, if one is prepared to accept resetting the window of in-flight packets during NAT rebinding or firewall state re-establishment, which seems reasonable to me. The tradeoff here then becomes number of bits per packet versus strength of assurance of the association and confirmation signal. I'll note that we have lots of experience with 32 bit packet number equivalents in TCP, here, though with Connection ID as an additional source of bits to resist off-path attacks, we might be able to get by with fewer.

> packet number.  I think that it's possible.

Why not, though this is primarily a question of requirements: an encrypted packet number/echo would be difficult to use for measurement, and practically impossible to use for state re-establishment. A mechanism allowing endpoint verification of packet and echo number integrity, though, would maintain this utility while reducing reward to the meddlers.

Cheers,

Brian