-
Notifications
You must be signed in to change notification settings - Fork 564
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
HTTP:// URIs over TLS #315
Comments
See a breakdown of terminology at: |
The description of this topic still only lists draft-nottingham-http2-encryption as an approach. Please add draft-hoffman-httpbis-minimal-unauth-enc, which does opportunistic encryption in a very different way than draft-nottingham-http2-encryption. |
Discussed in Zurich; further discussion in London; mark and patrick to revise draft and experiment. However, this will not block HTTP/2 unless delay is minimal. |
Notes from Zurich: HTTP URIs over TLS
Authentication
Discoverya. In-band Hint (header) - optional to use. b. DNS -- not now. c. use existing 443 connection for defaulted ports - some interest (esp. in addition to other mechanisms); needs refusal. SETTINGS indicator for support; refusal error code (?) d. encryption inside HTTP/2 -- no e. speculative connection -- we will say nothing about this Add-onsi. Refusal (you got the endpoint wrong) ii. implicit shortcut iii. pinning |
It would be good if the community could acknowledge the differences between opportunistic (doing something good that wasn't asked for) and unauthenticated (a security state). --Paul Hoffman |
Discussed in London; support for documenting this. |
See also: http://tools.ietf.org/html/draft-hoffman-uta-opportunistic-tls-00 |
@mnot What are the fundamental difference between opportunistic TLS and RFC 2817? |
@mcilvena take it to the mailing list? RFC2817 is quite different than the current Alt-Svc proposal. See http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-03 |
https://tools.ietf.org/html/draft-nottingham-http2-encryption-03 is the latest proposal in this regard. |
Discussed in NYC; agreed to adopt as WG Experimental. Martin to edit. |
One of the approaches considered for improving security is opportunistic encryption.
Two variants have been discussed; "relaxed" where server authentication is not checked, and "strict", where it is. In discussion, it appears that there's a preference for just using HTTPS URLs over "strict", but there is still some interest in "relaxed."
There appears to be some implementer interest in this approach, but not yet readiness to implement, so this issue is on hold.
Note that opp encryption might also be applied to HTTP/1.1.
The text was updated successfully, but these errors were encountered: