Subject: [quicwg/base-drafts] don't allow 0 as a packet number (#832)

From: Marten Seemann <[email-masked]>
Date: Tue, 03 Oct 2017 23:29:14 +0000 (UTC)

This would make implementations a lot easier (especially ACK generation).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832

---

From: MikkelFJ <[email-masked]>
Date: Wed, 04 Oct 2017 00:04:31 -0700

I agree

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-334067548

---

From: Nick Banks <[email-masked]>
Date: Wed, 04 Oct 2017 13:40:00 +0000 (UTC)

Personally, I don't think it makes it easier. If we add this restriction, we would have to update our implementation to add **extra special case logic** for packet number randomization to not allow 0, and then on the receive side of things, always check to see if packet number was 0 and drop it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-334158240

---

From: Marten Seemann <[email-masked]>
Date: Wed, 04 Oct 2017 13:46:28 +0000 (UTC)

That's a little extra logic (one if for generating and one if for receiving). By allowing 0 with the probability of 2^-31 we lose the ability to check that `highest received packet number != 0`, which will already is problem for several implementations, and will produce some really nasty corner cases in the future.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-334160224

---

From: Nick Banks <[email-masked]>
Date: Wed, 04 Oct 2017 13:56:02 +0000 (UTC)

But why do you need this? Are you just trying to track if you have received any packet? If so, wouldn't a separate flag for that case work just as easily? Or a counter for number of packets received?

> the ability to check that the `highest received packet number != 0`

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-334163264

---

From: Marten Seemann <[email-masked]>
Date: Wed, 04 Oct 2017 14:00:05 +0000 (UTC)

Correct, the alternative would be creating bools to track if the first packet was already received, just to cover an extremely improbable corner case in the packet number randomisation.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-334164612

---

From: Nick Banks <[email-masked]>
Date: Wed, 04 Oct 2017 07:02:19 -0700

If you don't like using a Boolean, keep a counter, which could have other uses, such as a statistical measurement.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-334165337

---

From: ianswett <[email-masked]>
Date: Wed, 04 Oct 2017 14:06:54 +0000 (UTC)

Stats are useful, but it'd nice to keep my stats code separate from my framing code.  Marten's right, this is definitely annoying to deal with, probably on the send side as well, since our code initializes packet numbers to 0 everywhere under the thought that 0 is an invalid packet number.  

It's really nice to have an invalid packet number constant, and using 0 as an invalid packet number is a lot better than using some other value in my opinion(ie: 2^64-1)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-334166761

---

From: Nick Banks <[email-masked]>
Date: Wed, 04 Oct 2017 07:09:54 -0700

If we really must have an invalid packet number I would also prefer 2^64-1, as that would never be initialized to, since we use 32 random bits, and we would essentially limit the maximum number allowed by 1. Really, no additional logic required.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-334167698

---

From: ekr <[email-masked]>
Date: Wed, 04 Oct 2017 07:31:49 -0700

I agree with @nibanks, but it's worth noting that it's also easy to produce
a value that is nonzero:

33s | <30 random bits> | 1

On Wed, Oct 4, 2017 at 7:09 AM, Nick Banks <[email-masked]> wrote:

> If we really must have an invalid packet number I would also prefer
> 2^64-1, as that would never be initialized to, since we use 32 random bits,
> and we would essentially limit the maximum number allowed by 1. Really, no
> additional logic required.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/832#issuecomment-334167698>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABD1oSeL0dqALA_JqDmJwi_ENpQVdeCSks5so5GwgaJpZM4Ps6XH>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-334174957

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 04 Oct 2017 08:19:25 -0700

I also completely agree with the idea that 0 is an invalid packet number to
simplify tracking.

On Wed, Oct 4, 2017 at 7:31 AM, ekr <[email-masked]> wrote:

> > <https://github.com/quicwg/base-drafts/issues/832#issuecomment-334167698
> >,
> > or mute the thread
> > <https://github.com/notifications/unsubscribe-
> auth/ABD1oSeL0dqALA_JqDmJwi_ENpQVdeCSks5so5GwgaJpZM4Ps6XH>
>
> > .
> >
>
> —
> <https://github.com/quicwg/base-drafts/issues/832#issuecomment-334174957>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ASp6yqdPSz1aDBWc_ubmNZSfdeexSA7Jks5so5bVgaJpZM4Ps6XH>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-334191017

---

From: janaiyengar <[email-masked]>
Date: Wed, 04 Oct 2017 16:48:12 +0000 (UTC)

Zero should not be allowed. Zero is a special number, it should be treated as such.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-334218462

---

From: pravb <[email-masked]>
Date: Wed, 04 Oct 2017 16:48:50 +0000 (UTC)

Any special packet number precludes packet number wraparound in future. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-334218694

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 04 Oct 2017 18:03:45 +0000 (UTC)

Not really, it just requires careful handling.

On Wed, Oct 4, 2017 at 9:48 AM, pravb <[email-masked]> wrote:

> You are receiving this because you commented.
> <https://github.com/quicwg/base-drafts/issues/832#issuecomment-334218694>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ASp6yroXdBK3j8P0iTXGzKmOTA93JFBHks5so7bygaJpZM4Ps6XH>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-334240615

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Oct 2017 17:00:08 -0700

1. s/largest_packet_number_I_will_automatically_discard/smallest_packet_number_I_might_accept/g
2. profit

Special values are almost never a good idea.  If we mandate 1, then we might have code that either can't properly handle a 0 if one is sent.  We certainly will have a lot of unused special case code for that number.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-336313368

---

From: Patrick McManus <[email-masked]>
Date: Fri, 13 Oct 2017 14:30:37 +0000 (UTC)

we have stream id 0 (though it is special for the connection - its not special for stream manipulation).. and offset 0.. and a connection id sequence number that starts at 0. 

If we go with martin's proposal re 62 bit integer encoding, there are billions of integers to use as sentinels in an implementation with a 64 bit int without overloading ones that can be transferred on the wire and cause interop pain.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-336469662

---

From: MikkelFJ <[email-masked]>
Date: Fri, 13 Oct 2017 14:40:17 +0000 (UTC)

I see the argument of avoiding sentinels, but at least in the C programming language, there is a massive amount of boilerplate code to initialize various structs that could just have been zeroed. There there are numerous additional checks to see if a value is uninitialized instead of just comparing with the previously received value. A much simpler check is to ensure that whatever you receive is larget than what you have: it then becomes illegal to send zero. But it is also illegal to send something smaller in many cases, for example data limits. In this context treating 0 as special makes a lot sense. From an algebraic point of view, 0 also has special signficance amongst the countable objects.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-336472424

---

From: Lars Eggert <[email-masked]>
Date: Thu, 19 Oct 2017 07:17:25 +0000 (UTC)

Maybe I'm too much of a TCP guy, but I had implicitly assumed that packet numbers were like TCP sequence numbers and operated on with modular arithmetic? Any reason this is not a good idea?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-337820785

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Oct 2017 08:35:14 +0000 (UTC)

The packet number is input to the AEAD nonce.  If you wrap around, you use the same nonce twice.  That's basically fatal for the ciphers we use.  We could allow a wrap around, maintain a counter on each wrap around and concatenate the two, but these are really big numbers and maybe it's not worth it.  You would also need to rekey many times with some ciphers (AES) or the cipher essentially wears out.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-337838510

---

From: MikkelFJ <[email-masked]>
Date: Thu, 19 Oct 2017 12:31:07 +0000 (UTC)

You could also consider a packet number wrap to be a rekeying event. Once you have new keys the AEAD nonce concern is gone.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-337892734

---

From: MikkelFJ <[email-masked]>
Date: Thu, 19 Oct 2017 15:19:17 +0000 (UTC)

To be more specific - AES-GCM should only use the same key for at most 2^32-2 nonces, i.e. packet numbers and in praxis less than that due to some possible attacks on GCM tags (the hash is computed on plain text for maxium parallelization, but that apparently has a cost in security).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-337941692

---

From: ekr <[email-masked]>
Date: Thu, 19 Oct 2017 16:12:18 +0000 (UTC)

"To be more specific - AES-GCM should only use the same key for at most 2^32-2 nonces, i.e. packet numbers and in praxis less than that due to some possible attacks on GCM tags (the hash is computed on plain text for maximum parallellization, but that apparently has a cost in security)."

The limit we converged on for TLS is: 2^{24.5}
https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#limits-on-key-usage

You can find the reference that led us to that here:
http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-337958330

---

From: MikkelFJ <[email-masked]>
Date: Thu, 19 Oct 2017 16:29:20 +0000 (UTC)

@ekr thanks for links. FWIW I thinks those limits on key usage in the TLS spec ought to be a MUST, not a SHOULD. Maybe 2^24.5 is conservative, but there is a point where GCM it falls apart more so than some ciphers. (GCM is fine, but only when respect its limits).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-337963262

---

From: janaiyengar <[email-masked]>
Date: Wed, 25 Oct 2017 19:21:01 +0000 (UTC)

@larseggert because there's no reason to repeat that mistake? It's annoying and bug-attracting to do modulo arithmetic everywhere in the code.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-339441734

---

From: Lars Eggert <[email-masked]>
Date: Thu, 26 Oct 2017 00:01:33 -0700

There's that. And I'm OK if we do it otherwise, but then let's be very clear about it, to avoid confusing TCP-heads like myself.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/832#issuecomment-339571246