The additional expense of HTTPS arises from the significantly higher cost to the service owner of protecting it against attack, to maintain service Availability (that third side of the security CIA triangle that gets forgotten).
Encryption should be activated only after BOTH parties have mutually authenticated. Why establish an encrypted transport to an unknown attacker? This might be done with mutual authentication in TLS (which nobody does) or creating a separate connection after identities are authenticated, or use an App with embedded identity. I'll be at RIPE70. Steve On Monday, April 13, 2015 at 3:57:58 PM UTC+1, Richard Barnes wrote: > There's pretty broad agreement that HTTPS is the way forward for the web. > In recent months, there have been statements from IETF [1], IAB [2], W3C > [3], and even the US Government [4] calling for universal use of > encryption, which in the case of the web means HTTPS. > > In order to encourage web developers to move from HTTP to HTTPS, I would > like to propose establishing a deprecation plan for HTTP without security. > Broadly speaking, this plan would entail limiting new features to secure > contexts, followed by gradually removing legacy features from insecure > contexts. Having an overall program for HTTP deprecation makes a clear > statement to the web community that the time for plaintext is over -- it > tells the world that the new web uses HTTPS, so if you want to use new > things, you need to provide security. Martin Thomson and I drafted a > one-page outline of the plan with a few more considerations here: > > https://docs.google.com/document/d/1IGYl_rxnqEvzmdAP9AJQYY2i2Uy_sW-cg9QI9ICe-ww/edit?usp=sharing > > Some earlier threads on this list [5] and elsewhere [6] have discussed > deprecating insecure HTTP for "powerful features". We think it would be a > simpler and clearer statement to avoid the discussion of which features are > "powerful" and focus on moving all features to HTTPS, powerful or not. > > The goal of this thread is to determine whether there is support in the > Mozilla community for a plan of this general form. Developing a precise > plan will require coordination with the broader web community (other > browsers, web sites, etc.), and will probably happen in the W3C. > > Thanks, > --Richard > > [1] https://tools.ietf.org/html/rfc7258 > [2] > https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/ > [3] https://w3ctag.github.io/web-https/ > [4] https://https.cio.gov/ > [5] > https://groups.google.com/d/topic/mozilla.dev.platform/vavZdN4tX44/discussion > [6] > https://groups.google.com/a/chromium.org/d/topic/blink-dev/2LXKVWYkOus/discussion _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
