Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-start session hash and Finished hash in mismatched case #104

Closed
ekr opened this Issue Dec 22, 2014 · 4 comments

Comments

Projects
None yet
4 participants
@ekr
Copy link
Contributor

commented Dec 22, 2014

See Figure 2,

"[[OPEN ISSUE: Do we restart the handshake hash?]]
[[OPEN ISSUE: We need to make sure that this flow doesn't introduce
downgrade issues. Potential options include continuing the handshake
hashes (as long as clients don't change their opinion of the server's
capabilities with aborted handshakes) and requiring the client to send
the same ClientHello (as is currently done) and then checking you get
the same negotiated parameters.]]"

Re-starting the hashes is conceptually cleaner, but needs security
analysis.

@grubba

This comment has been minimized.

Copy link

commented Dec 30, 2014

As the HelloRetryRequest affects the clients handling of the later ServerHello (last paragraph of 7.4.2.4), it would probably be prudent to have at least it in the handshake hash.

@martinthomson

This comment has been minimized.

Copy link
Contributor

commented Dec 30, 2014

@grubba, I think that this is a topic you should take up on the mailing list: tls@ietf.org

@enygren

This comment has been minimized.

Copy link

commented Jun 22, 2015

For the repeated ClientHello case (in the face of HelloRetryRequest), what about having HelloRetryRequest always contain a cookie (similar to in HelloVerifyRequest) and require repeated ClientHellos to replay that cookie. If that cookie is an HMAC by the server across an key held by the server, any server extra data (client ip?), and the invariant part of the ClientHello, then the server can revalidate the ClientHello without needing to keep any state about it. The handshake hash would contain the cookie (which includes an HMAC of the initial ClientHello that the server should revalidate against the new ClientHello). This aligns well with DTLS HelloVerifyRequest and also allows the first ClientHello to be excluded from the handshake hash, and then makes things like DTLS and any future client-puzzles extension work fit in fairly cleanly.

@ekr

This comment has been minimized.

Copy link
Contributor Author

commented Jun 22, 2015

I certainly think we want a cookie here because I want to merge HelloVerifyRequest and HelloRetryRequest. I'm less sure that the "verify that it was sent without changes" plan is practical, but it's certainly something we can explore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.