See also: IRC log
<mkwst> scribe: mkwst
bhill2: This is an idea at the
"collection of interesting ideas" phase.
... no one's implemented, just freeform discussion.
... came up this summer during berlin F2F.
... "How do we encourage more HTTPS"?
<mt_____> "just turn off http://"
bhill2: what are obstacles.
... how do we get there without a flag day, without damaging
the link structure of the web, etc.
<npdoty> When mkwest says "collection of interesting ideas", he usually has a complete draft of the spec :)
bhill2: Traditional wisdom: "Why
aren't you on HTTPS" -> getting a cert is a pain.
... Let's Encrypt solves that! All done!
... Let's assume that Let's Encrypt gives you certs, and it
just comes with Apache.
... If I have a modern website, I still can't just flip the
switch.
... Because of Mixed Content.
... [explains dependency problem: http can load https, but not
vice versa]
... I don't want to just flip over to HTTPS, because users will
get a bad experience.
... Even if I just publish it, HTTPS Everywhere will find it,
Google will promote it in search, etc.
... Users are going to have a bad time until I do a lot of
work.
... Why is mixed content a problem?
... Do I need to go into this?.
<npdoty> Completely hypothetical example of large static site like w3.org
[No.]
bhill2: How do we fix mixed
content?
... Upgrade-Insecure-Requests is one answer.
... Just upgrades all requests from http to https, assertion
from the site that the resources are semantically
equivalent.
... If I just add this header, many problems are fixed.
<inserted> explanation of upgrade-insecure-requests
bhill2: Deadlock in upgrading if
one dependency isn't upgraded.
... Deadlocks cascade. Dependencies between websites create
upgrade problems.
... How do we break the deadlock?
... Introduce an intermediary state.
<npdoty> Opportunistic, I think, right?
bhill2: Like opportunistic
encryption, but with similar properties to "real"
encryption.
... Keep "principle of tranquility" by not treating it as
secure in the UI (like OE)
... But this optimistic mode would not be treated as mixed
content for subresource loads.
... Zero cost, zero risk. Happy users. Anyone depending on me
is unblocked.
<npdoty> I'm not sure what "optimistic" means, or if it's synonymous to opportunistic... Or if opportunistic is well defined either
bhill2: Would it be sufficient to
allow everything but HTML pages?
... Iframes cause problems, because dependencies that go from
HTML to HTML across origin boundries.
... Idea to solve this is the transitional mode via a new ALPN
protocol.
... [explains ALPN]
... [https://tools.ietf.org/html/rfc7301]
... Client indicates protocols it's willing to support, server
chooses one.
... No additional roundtrip.
... Origin A that depends on Origin B can load resources from
origin B iff Origin B supports the transitional mode:
... Initiate a connection to B on 443, tell the server that you
support either "real" HTTPS or transitional HTTPS.
... Server can decide what to deliver back to the client.
?: What's different from server B's point of view?
bhill2: Transitional provides a
few things.
... 1. It provides a contract which says
... The content provided over transitional is semantically
identical to the response it would give over HTTP.
... http://forbes.com !=
https://forbes.com
... This gives assurances that the two are the same.
martin: HSTS is a signal of equivalence.
[side conversations]
JeffH: HSTS isn't equivalence. It breaks HTTP and replaces it.
martin: It also states that on the transitional indicator. This is analogous to the HSTS signal.
JeffH: But two different policies.
rbarnes: I don't understand the
distinction you're making.
... HSTS says that the authoritative version is HTTPS.
JeffH: And HSTS says that there is no HTTP version.
rbarnes: But either way, you're going to HTTPS, right?
dan: That works if you're the provider, but not if you're the consumer of those resources.
rbarnes: Non-determinism is a solvable problem. I have a proposal for priming that's floating around.
zcorpan: What should the client do differently when this is present?
bhill2: Two modes: when you fetch
a resource as a top-level resource, and when the content is
loaded as a subresource.
... When A loads B over transitional, A doesn't have mixed
content warnings.
... When B is a top-level navigation, you upgrade the
transport, but don't treat it as secure.
<npdoty> You don't enforce Mixed Content blocking and you don't show a nice lock icon?
dbaron: When it's a subresource of an HTTPS resource, right?
bhill2: When transitional is
loaded as top-level, UA doesn't show a lock lock, won't claim
to be HTTPS, won't block mixed content.
... Don't provide a bad experience for my users, and folks who
depend on me can do so securely.
rbarnes: What about iframed iframes?
bhill2: Right. Insecurely framed documents would still break. This doesn't fix them.
martin: How do you get to transitional for origin B?
<npdoty> Are we incentivized to just all go to transitional?
bhill2: Land on it with HTTP, and either the browser tries 443 optimistically, or we do alt-src header.
mnot: Probably need to do the latter.
bhill2: Sure. Maybe we do that in the future, maybe HTTPS Everywhere makes that a pref. Who knows.
[something about upgrade-insecure-requests that I missed.]
bhill2: If you have
upgrade-insecure-requests set, it attempts the load over
443.
... Right now, folks don't want to turn that on because it
exposes users to broken experiences.
... Can do it optimistically without providing broken
experiences.
yoav: Transitional gives you the option of upgrading?
bhill2: Right. There's
practically zero risk of breaking clients with
transitional.
... User would never see a mixed content warning by visiting
your page.
yoav: What are the advantages of
using this? You don't get service workers, no secure contexts,
etc?
... But you do get HTTP/2, right?
bhill2: Transport layer is
distinct. You get all that, but you don't get the promises of
HTTPS. No mixed content, no secure context, etc.
... Eventually I can flip a second switch, say "I'm tranquil.
Sure, you said HTTP, but I'm really HTTPS, so enforce all that
on me."
martin: Couldn't you just HSTS at that point?
bhill2: Sure, but there are billions of links in databases.
tim: Paper documents!
JeffH: The intention ... this
could be a rathole ... The HSTS policy statement doesn't imply
that anything is available over HTTP.
... Even though there's URL rewriting, what drove us to flip
the scheme was usability on the user's part.
... Not to make a statement that HTTP is semantically
equivalent to HTTPS.
rbarnes: Maybe morally you're not, but effectively you are.
bhill2: HTTPS categorically
blocks because of mixed content in status quo.
... Network stack folks don't want to change that.
... Contract is also to developers: fail fast, fail hard.
... Enables a gradual transition rather than flag days and
emergency sirens.
JeffH: This policy is about semantic equivalents. HSTS doesn't make that promise.
tim: The promise is relevant for
semantic web.
... Devices do canonicalization on URLs anyway.
... Will there be an API to look at my XHR in some way to tell
me about the commitments made by the other side?
bhill2: URL wouldn't change. Just
behind the scenes guts.
... URL doesn't change, so you can implicitly assume the
semantic equivalence.
<rbarnes> JeffH: i would be totally in favor of updating HSTS to make the statement of semantic equivalence
<rbarnes> since everybody already thinks it does :)
tim: Imagine I fetch one thing from a server, that gives me knowledge of that URI. What do I do for other URIs?
bhill2: This doesn't address
that.
... This lets you access a service over TLS that makes a
guarantee that a resource is semantically equivalent to the one
over a non-TLS channel.
... "Is there a way for an application to know that HTTPS ==
HTTP for an origin?"
... No, not today, and no that's not part of this
proposal.
... This lets you try a connection, and ensure that you get
such a resource back.
rbarnes: We should update HSTS so that it's a guarantee of equivalence.
JeffH: It would require changes to browsers.
tim: First write in the spec that
HSTS makes that commitment.
... Then, having that commitment, get the information to the
application.
JeffH: Altering the semantics of HSTS might be a way to address this if browsers are on board.
rbarnes: Given that the browser behavior 80% implements the equiv. right now, it seems simpler to just change it.
bhill2: That addresses Tim's use case, but not the more important use case of getting folks to TLS without a flag day.
JeffH: Maybe we could implement all this under the HSTS policy.
bhill2: I think you need a way to break the deadlocks.
rbarnes: Do you have examples of the deadlock problem.
tim: w3.org.
... He's in the building.
... You tell us to go to Ted, and tell him to turn on
HTTPS.
... circular dependencies.
bhill2: We have evidence of this. Easy. Ad networks.
rbarnes: This is a telemetry
problem.
... The word we used was "transitional". What gets folks to
transition?
tim: This works! we get to the
blue state!
... If everyone is blue, we're secure.
rbarnes: No, blue isn't secure!
bhill2: Blue lets you discover what content would have been loaded without mixed content blocking.
rbarnes: Maybe this is a
report-only mode of upgrade insecure requests.
... Maybe that's simpler to conceptualize than a third
mode.
bhill2: The blue state is easy! Don't care, we just turn it on for you.
fluffy: What if firewall blocks 443?
bhill2: Won't be worse than
status quo. If you don't send the alt-srv header, no risk of
breakage.
... The goal is turn it on, no breakage.
... This is meant to break the deadlocks.
... Once everyone is transitional because it's free, or, if not
everyone, more than status quo, deadlocks are broken.
... Which is a virtuous cycle.
timeless: What's the timeline? At what point could we just switch?
<scribe> scribe: yoav
bhill2: It would be simple to build this into nginx/Apache
<npdoty> scribenick: yoav
bhill2: Set your config to connect ALPN token to the right port
timeless: You want it in all
servers in the world
... So some sites will turn blue after a few months, and some
sites will never be blue
<dveditz> server stacks: apache, tomcat, iis, custom CDN stacks, etc
timeless: so after a while, we have to decide everything is green and everything will break
bhill2: You're probably right,
some sites will never upgrade and that's it, but at some point,
if we'd stop support
... there would be a flag day, but this will enable us to move
more people sooner
... by enabling more sites to move to that transitional
state
<rbarnes> BLUE IS NOT SECURE
tbl: supposed that we came back in 4 years and everything is blue, transitional but completely secure
timeless: I would be happy, but we'd switch it
mt_____: blue is vulnerable to
downgrade attacks, so you don't want that long term
... so it's not perfect, but better than nothing
mt: So we won't want to support
blue indefinitely
... maybe we can re-examine the HSTS thing
bhill2: Once I''ve set the tranquil flag you should treat the site as HTTPS, but I still have HTTP links
mt: What we want is to get everyone to secure state
bhill2: we want to get everyone there without breaking their sites, nor the guaranties
rbarnes: this proposal is
conflating two mechanisms
... one is getting better telemetry
bhill2: fixing mixed content breakage is very exepnsive, so the most important thing is unblocking dependers
rbarnes: it would be useful to break out all the parts because they may have different solutions
bhill2: I like it since it solves all the use cases
<npdoty> On that last point, it seems uncertain whether we can safely unblock people who depend on us by providing parallel http/https without endangering anything
rbarnes: but you're bundling the different use cases into a single solution
tbl: what telemetry would one
need? When measuring the dependencies don't we know what they
are but the graph is too complicated?
... the ability to go to blue stage is important
rbarnes: if we do the first two
things, we'd still have to get to blue stage
... but sites that I've worked with were able to get the first
two
... so once we've handled that we can know what we need to do
about the more complicated things
bhill2: thinking about cost and
incentive
... sites want the lock icons
... so they can use that to discover the dependencies and apply
pressure
rbarnes: the blue state removes pressure from the 3rd party to moving to HTTPS
tbl: if you're serving scripts you will get pressure
barryleiba: but you're getting nothing out of at
npdoty: if you're an ad network, you're losing money
mt: I'd like to push back on the
"just work" concept
... if you look into the details, there are a lot of
operational problems that this doesn't avoid
... we ran into problems, because you're running on TLS in a
modified mode, so resources are requested over blue mode and
green mode, and it's gets complicated to deploy this
... you're selling a silver bullet, and we've been there
bhill2: I'd love comments about these issues
<barryleiba> turns out to be a tin bullet...
mt: we've been discussing that
almost two years
... I'm suggesting that this shares some problems with
opportunistic encryption
mnot: I'd love to hear the editor of the mixed content spec
mkwst: If we can get the same
guaranties, it's not mixed content
... my concerns
... a) what thos guaranties are?
... the proposal addresses that, so if guaranties are provided,
resource doesn't load
... you lose confidentiality
... you keep the rest
... I'd love to keep confidentiality
... so that if we're coming from a secured context we request
443
... HTST probing forces you into HSTS which is
problematic
... what I've heard is that they can't do HSTS now, they dont
HTTPS
... HSTS is hard, so decoupling from HSTS is better
... my impression is that it resolves a small number of
sites
... it's not clear that it's worth doing the work
... and it doesn't solve the bigger problem of getting people
migrate
... what happens is that someone at the end of the chain
doesn't migrate
... which prevents everyone from migrating
... one option is the block mixed content, instead of loading
and breaking UI
<rbarnes> list of Let's Encrypt certificates
mkwst: ads not being HTTPS is
going away
... every publisher is moving to HTTPS
... so the guaranties of HTTPS are enough to get people to
migrate
... I'm sympathetic to the problems this is solving
... not clear this is relevant in a few years
... concerned about the amount of work that this would be
involved
... or if it's better to get more certs into hands of
people
... and resolving telemetry issue rbarnes talked about
... but people care and are working on it
... some sites will never upgrade, but not clear what we do
with them
... this proposal will get us to these sites, but I suspect
that there are a lot of them
... they probably not a dependencies so fairly isolated
bhill2: the rock they're under might be a government with data
mkwst: upgrading to HTTPS won't
solve it
... I think it's worth exploring, I want to understand
implications on ecosystem
... if it helps everyone upgrade, that's great
... or maybe we talk to large hosters and they just
upgrafde
bhill2: they can't necessarily upgrade because of crazy content that's linking anywhere
tbl: there was a plan to switch before TPAC, but too much stuff broke
mkwst: we asked questions and no answer
yves: problems with Firefox not implementing upgrade
mkwst: Safari didn't implement either, you need to cope
bhill2: thanks for showing up
[ Adjourned ]
<bhill2> adjourned!
<npdoty> Thanks, Brad!
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/need to invite zakim// Succeeded: s/APLN/ALPN/ Succeeded: s/XXX/zcorpan/ Succeeded: s/my IRC client won't do it unfortunately// Succeeded: s/How do one do that?// Succeeded: s/I'll try, if I know.// Succeeded: s|"/invite zakim https-transitional"|| Succeeded: s|someone did already|| Succeeded: s|Ah|| Succeeded: s/... How do we fix mixed content?/bhill2: How do we fix mixed content?/ Succeeded: i|explanation of upgrade-insecure-requests|-> https://w3c.github.io/webappsec-upgrade-insecure-requests/ explanation of upgrade-insecure-requests Succeeded: s/zcorpan/fluffy/ Succeeded: s/bhill/bhill2/ Succeeded: s/server/servers/ Succeeded: s/so after/... so after/ Succeeded: s/there would/... there would/ Succeeded: s/by/... by/ Succeeded: s/XXX/mt_____/ FAILED: s/XXX:/martin:/ Succeeded: s|s/XXX:/martin:/|| Succeeded: s|[explanation of upgrade-insecure-requests: https://w3c.github.io/webappsec-upgrade-insecure-requests/]|| Succeeded: s/... Deadlock in upgrading/bhill2: Deadlock in upgrading/ Succeeded: s/one/... one/ Succeeded: s/maybe we/... maybe we/ Succeeded: s/Richard:/rbarnes:/G Succeeded: s/bhill:/bhill2:/G Succeeded: s/q is dead// Succeeded: s/sites want/... sites want/ Succeeded: s/so they/... so they/ Succeeded: s/XXX/barryleiba/ Succeeded: s/if you/... if you/ Succeeded: s/ndoty/npdoty/ Succeeded: s/the ability to go/... the ability to go/ Succeeded: s/but sites that/... but sites that/ Succeeded: s/so once we've handled/... so once we've handled/ FAILED: s/XXX/barryleiba/ Succeeded: s|s/XXX/barryleiba|| Succeeded: s/so it's not perfect/... so it's not perfect/ Succeeded: s/Set your config/... Set your config/ Succeeded: s/we ran into problems/... we ran into problems/ Succeeded: s/you're selling a/... you're selling a/ Succeeded: s/my concerns/... my concerns/ Succeeded: s/a)/... a)/ Succeeded: s/the proposal/... the proposal/ Succeeded: s/you/... you/ Succeeded: s/you lose/... you lose/ Succeeded: s/I'd/... I'd/ Succeeded: s/so/... so/ Succeeded: s/HTST probing/... HTST probing/ Succeeded: s/what I've/... what I've/ Succeeded: s/HSTS is hard/... HSTS is hard/ Succeeded: s/it's not/... it's not/ Succeeded: s/and it doesn/... and it doesn/ Succeeded: s/what happens/... what happens/ Succeeded: s/which/... which/ Succeeded: s/one option/... one option/ Succeeded: s/ads not/... ads not/ Succeeded: s/every/... every/ Succeeded: s/so the/... so the/ Succeeded: s/not clear/... not clear/ Succeeded: s|so/I'm/... I'm|| Succeeded: s/I'm simpethetic/... I'm simpethetic/ Succeeded: s/concerned/... concerned/ Succeeded: s/simpethetic/sympathetic/ Succeeded: s/or if it's better/... or if it's better/ Succeeded: s/and resolving/... and resolving/ Succeeded: s/btu/but/ Succeeded: s/some/... some/ Succeeded: s/this/... this/ Succeeded: s/they/... they/ Succeeded: s|btw, list of Let's Encrypt certificates: https://crt.sh/?Identity=%25&iCAID=7395|-> https://crt.sh/?Identity=%25&iCAID=7395 list of Let's Encrypt certificates| Succeeded: s/but people care/... but people care/ Succeeded: s/XXX/yves/ Succeeded: s/or maybe we/... or maybe we/ Succeeded: s/if it's helps/... if it helps/ Succeeded: s/I think it's worth/... I think it's worth/ Succeeded: s/timeless/scribe/ Found Scribe: mkwst Inferring ScribeNick: mkwst WARNING: No scribe lines found matching previous ScribeNick pattern: <yoav> ... Found Scribe: yoav Inferring ScribeNick: yoav Found ScribeNick: yoav Scribes: mkwst, yoav ScribeNicks: yoav, mkwst WARNING: No "Topic:" lines found. Present: tbl dveditz dbaron LarsG Got date from IRC log name: 28 Oct 2015 Guessing minutes URL: http://www.w3.org/2015/10/28-https-transitional-minutes.html People with action items: WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]