Subject: [quicwg/base-drafts] Duplicates are dropped (#1624)

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Jul 2018 22:53:33 -0700

It's a little surprising that we didn't say this already.

I thought about a mention of the security considerations in the TLS
draft with this change, but I think that's unnecessary at this point.

Closes #1405.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1624

-- Commit Summary --

  * Duplicates are dropped

-- File Changes --

    M draft-ietf-quic-transport.md (5)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1624.patch
https://github.com/quicwg/base-drafts/pull/1624.diff

-- 
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/pull/1624

---

From: Marten Seemann <[email-masked]>
Date: Tue, 31 Jul 2018 23:12:08 -0700

We didn't say this because it's not necessary. There's no harm (other than a performance hit) in processing any frame more than once.

-- 
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/pull/1624#issuecomment-409460824

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 31 Jul 2018 23:28:39 -0700

I agree with @marten-seemann here.

If we are to add some text, I think that we should have a reference to the TLS document that states how it should be done, i.e.
> If the recipient of a packet discards packets with duplicate packet numbers without attempting to remove packet protection they could reveal through timing side-channels that the packet number matches a received packet. For authentication to be free from side-channels, the entire process of packet number protection removal, packet number recovery, and packet protection removal MUST be applied together without timing and other side-channels.
> https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#rfc.section.9.3

-- 
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/pull/1624#issuecomment-409463893

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Jul 2018 23:29:44 -0700

Some of us assumed that this was how it had to work.  Mainly because it is hard to think of a good reason to allow acceptance.

Consider: what if the same packet number was used for different content?  Other than it completely breaking most AEADs, what was it that was acknowledged?

I can add a reference to Section 9.3 of the TLS doc.  I didn't think that it was necessary, but it's easy to do.

-- 
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/pull/1624#issuecomment-409464106

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Jul 2018 23:31:17 -0700

@martinthomson pushed 1 commit.

57c1d36  Reference security considerations regarding packet protection

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1624/files/4bfd387a264e81fe2d79b9de073a5c9f551001a9..57c1d360d49a186605329375d5a5fcb6312d04b8

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 31 Jul 2018 23:54:17 -0700

@martinthomson 
> Some of us assumed that this was how it had to work. Mainly because it is hard to think of a good reason to allow acceptance.

I prefer using MAY rather than MUST.

The reason is because there is no need to enforce every stack to be written that way. For example, a QUIC stack can do the following:
* discard a newly received packet if it contains a PN in the ack queue
* retire PNs from ack queue after some time

This would work completely fine, even though it has the chance of processing a packet with same PN more than once.

If it is a MUST, every stack will be required to have a bit vector and a minimum threshold to detect all duplicates and also other awfully reordered packets. I understand that it is possible to implement such a mechanism. However, I simply think that it is not necessary.

> Consider: what if the same packet number was used for different content? Other than it completely breaking most AEADs, what was it that was acknowledged?

My understanding is that AEAED is broken if the sender reuses a packet number for carrying different content. I think we do not need to consider how to handle a corrupt implementation in this respect.

> I can add a reference to Section 9.3 of the TLS doc. I didn't think that it was necessary, but it's easy to do.

Thank you for the addition!

-- 
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/pull/1624#issuecomment-409469398