Re: [quicwg/base-drafts] token-based greasing / initial packet protection (#3166)

[Kazuho Oku <[e-mail]>]

@martinthomson 
> This is a whole lot easier if we force the server to commit, because then the server has to manage the fallback case. It makes this more brittle, in the sense that you need to make the static key more durable, but I think that it would be reasonable to expect a server to do that. They probably have to manage session ticket keys in this way.

I agree that it would be a much easier if we require the servers to commit.

At the same time, I think session ticket encryption keys are not something we should compare with. This is because the impact of losing access to alternative initial salt leads to handshake timeout, while the loss of session ticket encryption key merely leads to a full handshake. We have had this discussion in ESNI, and we ended up adding a fallback (i.e. esni_retry_request) due to a request from one of the largest deployments of TLS. That's why I have so far thought that a fallback is necessary.

That said, it might be possible that we have different requirements than ESNI.

After all, this alternative set thing is about giving the servers the *option* to issue different initial salts to every recurring connection. A server that advertises an alternative set does not need to work that way; deployments that might lose the key can issue a static initial salt that works across all the connections, and that would still be a win for us.

Considering these aspects, I am tempted to drop downgrade from this PR and see how it goes.

-- 
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/3166#issuecomment-547745701