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

[Magnus Westerlund <[e-mail]>]

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