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

Add support for a hash-based Public Reset packet (#215) #20

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
3 participants
@ekr
Collaborator

ekr commented Nov 23, 2016

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.

Add support for a hash-based Public Reset packet. 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.
@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Nov 23, 2016

Member

Hey EKR,

Could you please open an issue to track discussion on this? Pull requests might not be seen by some people. Thanks.

Member

mnot commented Nov 23, 2016

Hey EKR,

Could you please open an issue to track discussion on this? Pull requests might not be seen by some people. Thanks.

@ekr

This comment has been minimized.

Show comment
Hide comment
@ekr

ekr Nov 23, 2016

Collaborator
Collaborator

ekr commented Nov 23, 2016

@martinthomson martinthomson changed the title from Add support for a hash-based Public Reset packet. The model here is that to Add support for a hash-based Public Reset packet Nov 28, 2016

@ekr ekr referenced this pull request Jan 24, 2017

Closed

Public reset #215

@martinthomson

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Feb 6, 2017

Member

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.

Member

martinthomson commented Feb 6, 2017

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

Authenticate public reset with a hash
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

Authenticate public reset with a hash
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

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Apr 28, 2017

Member

@ekr, can we close this in favour of #460?

Member

martinthomson commented Apr 28, 2017

@ekr, can we close this in favour of #460?

martinthomson added a commit that referenced this pull request Apr 28, 2017

Authenticate public reset with a hash
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.
@ekr

This comment has been minimized.

Show comment
Hide comment
@ekr

ekr Apr 28, 2017

Collaborator

@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

Collaborator

ekr commented Apr 28, 2017

@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

@martinthomson

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson May 1, 2017

Member

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.

Member

martinthomson commented May 1, 2017

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.

@ekr

This comment has been minimized.

Show comment
Hide comment
@ekr

ekr May 1, 2017

Collaborator

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?

Collaborator

ekr commented May 1, 2017

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?

@martinthomson

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson May 1, 2017

Member

Yep, that works perfectly. I was expecting that this would need to wait for Paris anyway.

Member

martinthomson commented May 1, 2017

Yep, that works perfectly. I was expecting that this would need to wait for Paris anyway.

@mnot mnot changed the title from Add support for a hash-based Public Reset packet to Add support for a hash-based Public Reset packet (#215) May 22, 2017

@martinthomson

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Jun 21, 2017

Member

Closing in favour of #20 based on discussion in Paris.

Member

martinthomson commented Jun 21, 2017

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

Merge pull request #20 from siyengar/max_crypto2
Add max crypto data extension text
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment