Subject: Re: [quicwg/base-drafts] Order of Coalesced Packets (#1287)

From: Mike Bishop <[email-masked]>
Date: Wed, 06 Jun 2018 05:41:33 -0700

Discussed in Kista:  Sender SHOULD coalesce in order of encryption level, but receiver MUST NOT stop processing packets in a datagram if it encounters one it cannot currently process.  An implementation could either skip (and drop) the unreadable portion, or could buffer it for when the keys are available, just as if the packets were received out-of-order.

-- 
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/1287#issuecomment-395054332

---

From: MikkelFJ <[email-masked]>
Date: Wed, 06 Jun 2018 05:59:57 -0700

What if the length if the bad portion cannot be derived (other than byte for byte trial decryption of next embedded packet)? Or what if the unencerypted header section makes no sense?

-- 
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/1287#issuecomment-395059534

---

From: Nick Banks <[email-masked]>
Date: Wed, 06 Jun 2018 06:04:16 -0700

If something is wrong with a first (only?) packet header, then you can't even know there is another coalesced packet after it. You can only just throw it all away.

-- 
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/1287#issuecomment-395060731

---

From: MikkelFJ <[email-masked]>
Date: Wed, 06 Jun 2018 06:08:23 -0700

Exactly, so you cannot adhere to the MUST. The same applies if something is wrong in the second packet.

-- 
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/1287#issuecomment-395062022

---

From: Nick Banks <[email-masked]>
Date: Wed, 06 Jun 2018 06:11:49 -0700

I think it's a bit of a semantic issue at this point. In my mind, as the receiver of the packet, if something is wrong with the header, I can only assume there were no more packets and I am therefore not violating the MUST by throwing it away. Either way, the MUST is not enforceable as far as I can tell.

-- 
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/1287#issuecomment-395063052

---

From: Mike Bishop <[email-masked]>
Date: Wed, 06 Jun 2018 13:49:32 -0700

It's enforceable insofar as, if you violate it, a peer that persistently violates the SHOULD NOT will never interop with you.  It is required for compatibility that one side or the other comply with these recommendations; which one is a SHOULD and which a MUST is strictly a tiebreak.

-- 
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/1287#issuecomment-395208946

---

From: Mike Bishop <[email-masked]>
Date: Wed, 06 Jun 2018 13:55:42 -0700

@mikkelfj, this isn't targeted at a corrupted packet, but a well-formed one where you can tell from the headers that you don't yet have the keys.  For example, a coalesced packet containing (0-RTT | Initial) -- the server won't be able to read the 0-RTT portion.  It MUST skip to the second packet and process the Initial, though it is free to discard or return to the 0-RTT packet once that's done.

-- 
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/1287#issuecomment-395210799

---

From: Martin Thomson <[email-masked]>
Date: Fri, 08 Jun 2018 06:47:58 -0700

A packet can always be decoded as though it were valid.

A short header will either be too short or it will be sent to the AEAD to fail decryption.

Long headers are a little trickier, but not overly so.  If it is too short, it is discarded.  The difference is that it has an explicit length.  If the length is too short or too long, it is discarded.  Then you pass to the AEAD to fail decryption.  Only in that case do you need to worry about what comes after.

My question is: if the connection ID doesn't match, can the recipient discard the entire datagram?  We require that the connection IDs are consistent across the entire datagram.  I think that it would be reasonable to discard in that case.

-- 
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/1287#issuecomment-395765891

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Jun 2018 16:05:30 -0700

Closed #1287 via #1423.

-- 
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/1287#event-1677500472