Re: [quicwg/base-drafts] Server should not accept 1-RTT traffic before handshake completion (#3159)

[Martin Thomson <[e-mail]>]

This recommendation has been made a few times, but we have thus far resisted it on the basis of it not working with client authentication.

The suggestion that the server might offer proof that it didn't do something bad is new.  If I were inclined to take that suggestion seriously, I would instead say that the server should use an exporter to generate something.  You could even see how this might make its way into the proposed HANDSHAKE_DONE frame.

But I don't think that this needs this level of mechanism.  This is something that servers just need to do on their own.  Just like having a good source of randomness for their key generation, the consequences of failure here are that they might be open to attack.

I have no problem with test suites that purposefully "drop" critical packets to reveal misbehaving servers.  That might be better than adding mechanism.

That said, the server can just withhold ACK frames until it sees the whole handshake, even if it processes the entire handshake.  A server could answer requests from 1-RTT until clients start looking for that happening.  Ultimately, we can't stop the server from performing processing if it offers no reliable proof of that happening.  And I don't think that it's worth trying.

-- 
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/3159#issuecomment-547243572