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

require tls auth #234

Closed
mcmanus opened this issue Sep 7, 2016 · 5 comments
Closed

require tls auth #234

mcmanus opened this issue Sep 7, 2016 · 5 comments
Labels

Comments

@mcmanus
Copy link
Contributor

mcmanus commented Sep 7, 2016

1] opportunistic security should require TLS authentication. Any other approach undermines the opt-in mechanism of .wk. As the PKI market has matured to allow truly free and automated certs certificate availability is no longer the chief barrier to https, and so opportunistic security should feel comfortable requiring real authentication. (THERE IS NO PROPOSED CHANGE IN THE SECURITY MODEL - HTTP:// IS STILL HTTP:// AND NOT GRANTED HTTPS:// STATUS AT ALL). The biggest barrier to https:// at this point seems to be mixed content.

@mcmanus mcmanus added the opp-sec label Sep 7, 2016
@reschke
Copy link
Contributor

reschke commented Sep 8, 2016

Not convinced, in particular because it's a rather drastic change at this point. If authentication is OK, isn't it much easier just to redirect the client to the HTTPS port? Wouldn't we remove the main reason why this was specced in the first place?

@mcmanus
Copy link
Contributor Author

mcmanus commented Sep 8, 2016

I'm not sure what you mean by https port - which is indeed what this will
often accomplish by using TLS over 443. It will however not redirect them
to an https scheme (use 3xx for that).

The main reason for this spec would be for improving the use of http
schemed content that needs to remain that way for legacy reasons (chiefly
mixed content restrictions). https is going to be superior and you should
run it if you can. easy and free DV authentication has proven itself at
this point.

as for drastic at this point -there is no point in moving the document
along just for the sake of moving the document along if it doesn't reflect
the experiment. And what we found was that in order to take the opt in of
.wk seriously it needed to be authenticated.

On Thu, Sep 8, 2016 at 1:53 AM, Julian Reschke notifications@github.com
wrote:

Not convinced, in particular because it's a rather drastic change at this
point. If authentication is OK, isn't it much easier just to redirect the
client to the HTTPS port? Wouldn't we remove the main reason why this was
specced in the first place?


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#234 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAP5swMLfvCsvwXrrk9eoWpbsR8_uXENks5qn6LpgaJpZM4J3Ved
.

@mnot
Copy link
Member

mnot commented Sep 28, 2016

Question: is the intent to retain the requirement that the alternative service be on the same host?

mnot added a commit that referenced this issue Sep 28, 2016
@mcmanus
Copy link
Contributor Author

mcmanus commented Sep 28, 2016

@mnot [Question: is the intent to retain the requirement that the alternative service be on the same host?]

no such requirement now that we have auth and .wk

mnot added a commit that referenced this issue Oct 4, 2016
as per discussion in #234
@martinthomson
Copy link
Contributor

Resolved in the latest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

4 participants