Re: Proposed Statement on "HTTPS everywhere for the IETF"

Am Dienstag, 2. Juni 2015, 08:24:56 schrieb Harald Alvestrand:
> have you looked at your cable TV lately? Or your DAB radio?
Encrypting publically accessible TV vor radio content just could bring added 
value for the Distributor / provider - i.e. by avoiding any not paid usage by 
thirds or using other Hardware.

There is usually no value for the recipient (possibly except Pay-TV products), 
but significant less freedom and for this reason i.e. basic TV encryption in 
cable networks was prohibited by the federal cartel office these days here in 
germany (german):
http://www.heise.de/newsticker/meldung/TV-Grundverschluesselung-Freie-Sicht-bei-Unity-Media-1776052.html
 

> See the Great Cannon attack. Allowing in-flight modification of 
> resources (which using HTTP is) is not just a theoretical danger to 
> yourself, it's a practical danger to anyone on the Net.
HTTPS "Encryption" byself is not targeting MitM "modifications" - this is 
mainly a part of signatures (in HTTPS "realized" by "certificates"). Avoiding 
modifications MitN is (technically) possible "just" by signatures or hashes (in 
theory...).

HTTPs rely fully on signatures from any third Party a user has to trust in full 
plus he has to check the FULL certification path for each website he want to 
use (by theory...). 

It is not a simple question of "is it green in the Browsers line?" as the very 
most of users think today in practice... The browser distributors has no 
interest in changing that view, because the status quo leads to more dependence 
from their licensing politics. This is why some browsers i.e. make it more and 
more diffucult to use HTTPS in private networks where they have no fitting 
"SSL" product for.

If you just find ONE of the up to hundreds of Browser CAs (or at least some 
cross/sub CA contractor) today where one is providing you a certificate for and 
third Party you have it compromized "silently" even it it uses a "very famous 
and reliable and expansive CA product byself" - the browsers line "is green" 
while MitM - voila. Same happens with compromized CAs (remember i.e. the 
publically known Comodo hack some years ago...).

Beside the fact that HTTPs even delivers no "privacy" for the users of public 
static web content (public web sites, focussed document archives and mailing 
list archives i.e.) - what leaves as "added value" for them if you BLOCK HTTP 
for such content - i mean value which makes the costs of energy and resources 
worth?


> But since you're not convinced by the language of the IESG note, me 
> repeating it won't make you more convinced. Sorry 'bout that.
Sorry if i really misunderstanded a part of (reacted mainly onto other posts in 
this topic). If HTTP will be available for any public ("static") part of the 
IETF HTTP this would be fully OK for me - even "preferring" HTTPS over HTTP by 
HTTP redirects or similiar while offering a "button"/link (SSL/TLS "on/off" or 
"by hand") or similiar options (i.e. while using relative URL's)

Sorry for the noise, if so...

It would be nice if the IETF would be one instance helping to develope new and 
transparent standards the "todays" x509 HTTPS for trust and encryption, i.e. 
where users can decide which "CA" / "trustee" they want to trust (and possibly 
which algorithms) etc.pp. and don't have to "trust" any single third party 
company, government or organisation and away from the todays still static view 
onto SSL/HTTPS "security" (the incorrect "is it secure or not" paradigm).

I wrote (possibly a bit more then) "enough" now in this topic - will retract 
from now - sorry for the noise...


best regards,


Niels.

-- 
 ---
 Niels Dettenbach
 Syndicat IT & Internet
 http://www.syndicat.com
 PGP: https://syndicat.com/pub_key.asc
 ---

signature.asc
Description: This is a digitally signed message part.