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 ---
Attachment:
signature.asc
Description: This is a digitally signed message part.