Subject: Re: [quicwg/base-drafts] Handling of duplicate packets (#1405)

From: Magnus Westerlund <[email-masked]>
Date: Tue, 05 Jun 2018 06:38:19 -0700

>From my perspective processing the later arriving duplicate has risks. If this is an intentional attack based on duplicating and modifying  a packet, but where the original can't be removed, then likely the attack packet will arrive after the original. 

Secondly, trying to combine the ECN response of multiple packets is less than straightforward and exposes one to the risk above. It can also make one more likely to treat a specific ECN number as CE than none duplicated packets. Also the downside of dropping any duplicate packet even if CE marked is not significant. If you have a congestion event that results in the next packet is marked also, then the CE event will be reported one packet later. 

ECN for RTP (https://www.rfc-editor.org/rfc/rfc6679.txt) actually tracks duplication and loss as seen by receiver to give all variables, but the retrospective on that RFC is that is overly causes. 

I would argue that QUIC need a basic duplication handling, and that ECN processing happens after the packet has been decrypted and authenticated to avoid any type of injection attacks, and require additional checking mechanism for it being a valid source sent 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/1405#issuecomment-394712102

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 05 Jun 2018 07:29:53 -0700

Thank you for the explanation.

I now see that we need to decrypt the packet before updating the ECN counter.

And I think that detecting duplicates on an endpoint is not that complicated now that we have PNE, which means that we can assume that packet numbers will be used mostly contiguously (we might need to specify how frequently packet numbers can be skipped to detect optimistic ack attacks).

-- 
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/1405#issuecomment-394731145

---

From: Christian Huitema <[email-masked]>
Date: Wed, 06 Jun 2018 22:09:03 -0700

I think this discussion of duplicates illustrates a more fundamental issue with ECN: it is a signal from outside the encryption envelope that affects the behavior of the encrypted communication. In theory, all kinds of games are possible: adversarial ECN marking by an on-path device; copying of packets and reinjection with adversarial ECN markings by a man-on-the-side; copying of packets and reinjection with different IP headers and ports by an on-path device or a man on the side, possibly with the goal of messing up per-path ECN behavior. IMHO, the handling of ECN should be robust against these attacks, and the protection of ECN should not come from assumptions about how devices might or might not filter duplicate packets.

-- 
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/1405#issuecomment-395294672

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 15 Jun 2018 04:15:39 -0700

As discussed in https://github.com/quicwg/base-drafts/issues/1439#issuecomment-397589048, my understanding is that the ECN support in the form proposed in #1372 is the only issue that makes duplicate detection a requirement rather than an option.

Considering that, I think that we have a chance of closing the issue without adding any requirements if we adopt a different encoding scheme that lets the sender detect duplicates as discussed #1439.

-- 
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/1405#issuecomment-397590223

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Jun 2018 03:45:59 -0700

In regards to @kazuho comment: 

> As discussed in #1439 (comment), my understanding is that the ECN support in the form proposed in #1372 is the only issue that makes duplicate detection a requirement rather than an option.

So, do I assume correctly, that you will still throw away packets that are several RTTs old, i.e. that have a PN number older than any state? Or do you generate an ACK for that old packet that is so old, and try to find if there is any unconsumed buffers to put any data in?  

You might be right in that all existing frames have a behavior that if one applies it twice it already have the handling rules to suppress the duplicate or not cause any downside of being applied twice. I looked through the frame types and the only ones that I think have some impact are:
* Path_Challenge: A non duplication detecting receiver, will issue two Path_Response frames in response to a single PN. The sender of the Path_Challenge should not react badly to this. 

Also, I haven't considered if there are any new requirements with the handshake packets and the interaction with TLS? 

I would note that AES-GCM do have this weakness (Fergueson  http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf) that if one manage to know that one successfully forged a packet so that it passed the authentication verification, then one learns a number of bits of the authentication key, making the next forgery simpler. If it is possible to run such an attack by sending modified duplicates with forged authentication tags resulting in a response, then this can be exploited (https://link.springer.com/chapter/10.1007/978-3-319-31517-1_7). So QUIC will not use truncated tags, but QUIC connections may be very long lived in certain environments. Thus making it possible to maintain an attack for a sufficient time to possible have any result. Thus, I think for safety reasons packet duplication suppression after decryption should be mandatory to prevent this information leakage and not put that onto the individual frame types to consider if they will result in reveal of a successful forgery of a modified duplicate packet.   

I also noted that when we discussed this at the Interim it appeared that most, if not all except @kazuho was thinking that duplication suppression was expected in the receiver. If this is not required, then think the actual requirements on each frame type individually needs to be very clear. 

It would be good to come to a conclusion on this issue so that we can determine what is needed for the ECN addition (#1372).  

-- 
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/1405#issuecomment-398014741

---

From: MikkelFJ <[email-masked]>
Date: Mon, 18 Jun 2018 03:55:32 -0700

> Thus, I think for safety reasons packet duplication suppression after decryption should be mandatory to prevent this information leakage and not put that onto the individual frame types to consider if they will result in reveal of a successful forgery of a modified duplicate packet.

Rekeying must happen before that point.

-- 
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/1405#issuecomment-398016919

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Jun 2018 04:23:21 -0700

@mikkelfj I am uncertain if that happens in a way that will prevent this attack. My assumption when this attack would be possible would be a low rate management connection where any rekeying based on number of legit sent packets may occur very infrequently. I don't find what the rekeying frequency requirements are, does someone have pointer? 

The number of tested forges will be dependent on the number of forged duplicate packets the attacker manage to send without raising an alarm that the connection is under attack. But, if there are no such warnings then an attacker could potentially send a large number of attack packets without the target noticing other than it drops a lot of packets due to authentication failure. The attack only consumes PN and thus packets until rekeying when a successful forge has been accomplished. 

To my understanding the protection against this type of attack, is to prevent that a successful forge results in a response. If there are no general duplication protection then using a recently sent packet as attack packet is makes it simpler to cause a response. In fact the response to ECN-CE marks can actually be one thing that provides such a proof if some of the response discussed in #1372 would be allowed. Modifying the payload forging the authentication tag and setting the ECN bits to CE could then trigger an ACK on successful forge. For a connection that mostly idle that ACK will be a good signal for a forge. However, for this type of connection one can likely also target packets with a PING frame. Thus, also getting an ACK response on successful forge.

-- 
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/1405#issuecomment-398022746

---

From: MikkelFJ <[email-masked]>
Date: Mon, 18 Jun 2018 04:44:21 -0700

If keys are not updated within about 2^32 packets one might might as well introduce a new plain text option because it would achieve the same with less overhead.

- https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#rfc.section.6.2
- https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.5.5
- https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#AEAD-LIMITS
- 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/1405#issuecomment-398027221

---

From: MikkelFJ <[email-masked]>
Date: Mon, 18 Jun 2018 05:03:36 -0700

But I think you are right that QUIC should much more prominently document such a rekeying requirement. For example that a key update MUST happen no later than after 2^32 packet exhanges or earlier if specific AEAD mode requires this (but such modes probably shouldn't be permitted).

While some crypto modes could surve much more than 2^32 other modes would eventually fail badly (AES-GCM). By forcing an update no later than 2^32 it is easy to avoid implementation mistakes and for the peer to do a hard disconnect if keys are not updated. Silent crypto errors are really bad.

-- 
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/1405#issuecomment-398031584

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 18 Jun 2018 05:43:54 -0700

@gloinul 
> So, do I assume correctly, that you will still throw away packets that are several RTTs old, i.e. that have a PN number older than any state? Or do you generate an ACK for that old packet that is s…

My argument is that doing either would be fine.

> I looked through the frame types and the only ones that I think have some impact are:

My understanding is that the following statement in the transport draft section 5 covers this: "All QUIC frames are idempotent. That is, a valid frame does not cause undesirable side effects or errors when received more than once."

> I would note that AES-GCM do have this weakness (Fergueson http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf) that if one manage to know that one successfully forged a packet so that it passed the authentication verification, then one learns a number of bits of the authentication key, making the next forgery simpler. If it is possible to run such an attack by sending modified duplicates with forged authentication tags resulting in a response, then this can be exploited (https://link.springer.com/chapter/10.1007/978-3-319-31517-1_7).

If such attack is possible, it would be a vulnerability of the AEAD algorithm. It would be unrelated to if we detect duplicates. It is the task of the AEAD to provide authentication.

> I also noted that when we discussed this at the Interim it appeared that most, if not all except @kazuho was thinking that duplication suppression was expected in the receiver. If this is not requi…

My understanding is that the discussion was based on our understanding (at that point) that duplication detection on the receiver is a prerequisite for ECN to work, and that we did not agree on how strictly we should require that to be implemented on the receiver.

Considering that, I think that it would be fair to argue for looking into if duplication detection is actually required, considering the fact that now we now that ECN can be supported without 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/1405#issuecomment-398041417

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Jun 2018 05:49:49 -0700

The main point I like to stress, is that there will be a number of long lived connections that never will rekey if they are only based on sent packets. Even if one send 136 packets per second, the sender rekeys only once every year. And there are plenty of applications that will send less than a packet a second on average. The attack outlined is not affecting the number of sent packets by the sender in any significant way, it will only result in sending a lot of packets to the receiver and watch for signs of successful forgery by monitoring what the receiver emits back to the sender. Thus, if one can send 10000 packets a second to the receiver, then one will have had the possibility of sending ~2^38 packet by the time of rekeying. So still a low probability of success but not insignificant.   

-- 
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/1405#issuecomment-398042975

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Jun 2018 06:27:30 -0700

An important clarification about this attack: The attack on AES-GCM is definitely valid for truncated authentication tags. However, my co-author clarified to me that this is not an issue for untruncated tags. So as long as QUIC uses 128 bit authentication tags for AES-GCM we should have no issue from a cryptographic perspective.

I still think not having any requirement on replay protection at the main protocol level puts a lot of responsibility on the designers of extensions as well as implementers to ensure that things truly are idempotent when sent input. 

@kazuho 

> My understanding is that the following statement in the transport draft section 5 covers this: "All QUIC frames are idempotent. That is, a valid frame does not cause undesirable side effects or err…

This text is only in master and was not in -12, so I didn't see it at the time I wrote the ECN PR. I think the extensibility text probably needs an RFC 2119 requirement on that any new frame types needs to fulfill that requirement. But, to fulfill that for ECN, at least if there are no strict requirement on duplication suppression do requires the ECN specification to change. Either to do receiver side suppression of the ECN field value so that it doesn't matter, or change the encoding so that one handles the duplicated packets correctly. 

-- 
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/1405#issuecomment-398053419

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 18 Jun 2018 06:39:31 -0700

@gloinul 
> But, to fulfill that for ECN, at least if there are no strict requirement on duplication suppression do requires the ECN specification to change.

That's correct. Duplication suppression will be required if we adopt the encoding proposed in #1372.

I am merely pointing out that #1372 is the only thing that requires suppression, and that we have a chance of dropping the requirement if we adopt an alternative encoding as we have been discussing in #1439.

-- 
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/1405#issuecomment-398057102