Add support for a hash-based Public Reset packet (#215) #20
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
neither on-path nor off-path attackers should be able to forge one, but that on-path elements should be able to validate the public reset.
|
Hey EKR, Could you please open an issue to track discussion on this? Pull requests might not be seen by some people. Thanks. |
|
Hi Mark,
I already emailed the list. You want an issue as well?
…-Ekr
On Wed, Nov 23, 2016 at 3:04 PM, Mark Nottingham ***@***.***> wrote:
Hey EKR,
Could you please open an issue to track discussion on this? Pull requests
might not be seen by some people. Thanks.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#20 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABD1ofcEb3TINfUjWSXMXdjGMIEeyv3Tks5rBMZzgaJpZM4K7Gbu>
.
|
martinthomson
changed the title
martinthomson
added
design
martinthomson
added
the
needs-discussion
Closed
martinthomson
removed
the
needs-discussion
|
This is currently pretty badly bitrotten, we'll need to revisit this once we get some of the other work in place. This is blocked on transport parameters and header changes. |
martinthomson
added a commit
that referenced
this pull request
Apr 21, 2017
This takes ekr's design from #20 and expands on it quite a bit. There are a few little wrinkles that I think we might want to discuss a little. First, this is a one-time password, so the combination of key and connection ID can't ever be repeated for a given server instance. Our 64-bit connection ID space isn't really enough to provide this. How a server moves to a new static key during operation will be challenging; it probably needs to partition the connection ID space. Second, transport parameters are encrypted. #20 made a point of having the verifier in the clear so that intermediaries could validate the Public Reset.
martinthomson
added a commit
that referenced
this pull request
Apr 26, 2017
This takes ekr's design from #20 and expands on it quite a bit. There are a few little wrinkles that I think we might want to discuss a little. First, this is a one-time password, so the combination of key and connection ID can't ever be repeated for a given server instance. Our 64-bit connection ID space isn't really enough to provide this. How a server moves to a new static key during operation will be challenging; it probably needs to partition the connection ID space. Second, transport parameters are encrypted. #20 made a point of having the verifier in the clear so that intermediaries could validate the Public Reset.
martinthomson
added a commit
that referenced
this pull request
Apr 28, 2017
This takes ekr's design from #20 and expands on it quite a bit. There are a few little wrinkles that I think we might want to discuss a little. First, this is a one-time password, so the combination of key and connection ID can't ever be repeated for a given server instance. Our 64-bit connection ID space isn't really enough to provide this. How a server moves to a new static key during operation will be challenging; it probably needs to partition the connection ID space. Second, transport parameters are encrypted. #20 made a point of having the verifier in the clear so that intermediaries could validate the Public Reset.
|
@martinthomson I don't care about the Github mechanics, but I think these are trying to address different design constraints, specifically, whether we want the public reset to be invisible to the middlebox. And if we do want that, then we should make it indistinguishable to the middlebox rather than labelled but unverifiable |
|
Possibly a more relevant question then: do you intend to update this to track the changes in the draft? I plan to update #460, which might mean making it publicly verifiable, or making the reset indistinguishable, or whatever the working group ends up with. |
|
I was hoping we would have a discussion of the design constraints in Paris and then we can design the crypto to suit. Would that work for you? |
|
Yep, that works perfectly. I was expecting that this would need to wait for Paris anyway. |
mnot
changed the title
|
Closing in favour of #20 based on discussion in Paris. |
marten-seemann
pushed a commit
to marten-seemann/base-drafts
that referenced
this pull request
May 22, 2018
Add max crypto data extension text
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The model here is that neither on-path nor off-path attackers should be able to forge one, but
that on-path elements should be able to validate the public reset.