- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Wed, 18 Jul 2012 23:32:39 +1200
- To: ietf-http-wg@w3.org
On 18/07/2012 6:39 p.m., Mike Belshe wrote: > I won't comment on most of this - I think we've each made our points > and will need to respectfully disagree. One last point below. > > On Tue, Jul 17, 2012 at 10:43 PM, Adrien W. de Croy <adrien@qbik.com > <mailto:adrien@qbik.com>> wrote: > > > ------ Original Message ------ > From: "Mike Belshe" mike@belshe.com <mailto:mike@belshe.com> >> >> >> On Tue, Jul 17, 2012 at 9:51 PM, Adrien W. de Croy >> <adrien@qbik.com <mailto:adrien@qbik.com>> wrote: >> >> >> ------ Original Message ------ >> From: "Mike Belshe" mike@belshe.com <mailto:mike@belshe.com> >>> >>> >>> On Tue, Jul 17, 2012 at 8:25 PM, Adrien W. de Croy >>> <adrien@qbik.com <mailto:adrien@qbik.com>> wrote: >>> >>> Mandating use of (c.f. support for) crypto in HTTP will >>> prevent it from being deployable in a significant number >>> of scenarios, thereby requiring ongoing use of HTTP/1.1. >>> >>> >>> This is true for any manifestation of HTTP/2.0 with or >>> without security. >> I don't know if it should be a goal though. IMO the goal >> should be to replace the old with something better, not >> replace it with something that can only be used by a subset >> of current users, and therefore requires continued perpetual >> use of the old. >> >> >> Agree; goal should be to be better. That doesn't mean that I >> think everyone will jump to it in short order, though. > I don't expect anything to be jumped to in short order. > >>> DESIRABILITY OF PRIVACY >>> Proponents of mandatory crypto >>> are making an assumption that privacy is ALWAYS desirable. >>> It is not ALWAYS desirable. >>> In many cases privacy is undesirable or even illegal. >>> 1. Many states have outlawed use of crypto. So will >>> this be HTTP only for the "free" societies? Or is the >>> IETF trying to achieve political change in "repressed" >>> countries? I've dealt with our equivalent of the NSA on >>> this matter. Have you? I know the IETF has a neutral >>> position on enabling wiretapping. Mandating SSL is not >>> a neutral / apolitical stance. Steering HTTP into a >>> collision course with governments just doesn't seem like >>> much of a smart idea. >>> >>> >>> I don't know of states that prohibit TLS. Do they exist? >>> Which ones are they? Can you list them? >> It's hard to get recent information, but my understanding is >> that a lot of of people live in jurisdictions where crypto is >> tightly controlled. >> E.g. China, India, several mid-eastern and former soviet >> countries. >>> >>> Are you saying that HTTP/2.0 must be compliant with the laws >>> of every country? And that any country passing a law making >>> HTTP/2.0 features illegal will block HTTP/2.0? :-) >> In practice, we would have different levels of difficulty >> ignoring laws of a country depending on which country that was. >> If the US passed a law that banned it, and threatened to put >> you in jail, you may give that more weight. >> Governments already have wiretapping laws. Do you think they >> will abandon that as a desire? >> Many laws on crypto were only relatively recently relaxed. >> There's an ongoing tussle between security agencies of >> government and privacy advocates over it. We can't guarantee >> that within the next 5 years that any country wouldn't make >> it illegal. >> It's not like we can claim there's no reasonable expectation >> to consider laws when it comes to crypto. That's the one >> area of software development where caveats and warnings are >> stamped over so much code and documentation that we can't >> claim to be unaware it's an issue. >> >> >> >> Well, when you've got a specific country to talk about, please >> raise the issue. > Maybe someone from one of the countries I listed above would be in > a better position to comment than I am. >> >>> 2. Most prisons do not allow inmates to have privacy >>> when it comes to communications. Would you deny [*] all >>> prisoners access to the web? There are other scenarios >>> where privacy is not expected, permitted or desirable. >>> >>> >>> I doubt this is a problem. If it is, then the poor >>> prisoners are already being denied access to their banks, >>> most all of which require TLS. >> Maybe there's not much sympathy for prisoners. That's just >> one example. >> Schools, homes and businesses are also places where there may >> be deemed (by those in charge) a need to monitor activity. >> >> >> They already have this problem. Twitter, Google, and Facebook >> have all publicly declared that they are working their way to >> 100% TLS all the time. These issues exist today. If you want to >> filter TLS, you can; several vendors provide solutions. > Sure, and as said before, this is not without security implications. >> >> But schools have bigger problems - like those cell phones with >> more bandwidth than the school has to its classrooms. > Many schools ban cellphones. My son's school does. >> >> I don't think the protocol has an obligation to reduce security >> so that prisons, schools, or other institutions can institute >> content control. And by the time this standard is done, the >> policy rules will have changed again. > I'm not proposing we take the current level of security of > HTTP/1.1 and reduce it. > you're proposing we add TLS. Whilst that will provide a level of > privacy in many cases, I don't think it will overall result in an > improved security situation overall, especially if it breaks > SSL/TLS. I kinda like SSL/TLS, I'd like it to continue to be usable. >> >> A simple thing we do know is that users expect and deserve to be >> protected by the protocols and sites they visit. We're passing >> more laws every day to ensure this - and HTTP can help. > rubbish, we know no such thing. > all users are not equal. All users are not equally deserving of > privacy in all situations. > >> >>> 3. Many situations require communications to be open and >>> visible. Would you rather your network infrastructure >>> phoned home with SSL or HTTP that you can see. >>> >>> >>> Can you enumerate these? For debugging, of course it makes >>> sense for endpoints to have unencrypted modes. We can also >>> build better tools, such as the improvements for decoding >>> TLS traffic with Wireshark that have landed recently. >> Can only decode NULL cipher. >> >> >> With wireshark you can decide SSL session if you let your browser >> dump the private keys. Chrome supports this. >> http://www.imperialviolet.org/2012/06/25/wireshark.html > OK, well let's hope we never have to debug any protocol - level > stuff with any other client software. >> >> Huawei recently got excluded from bidding for an Australian >> govt contract (a large one) due to concerns over possibility >> of eavesdropping. >> >> >> Excellent point for why we should make the protocol more secure >> :-) If everything were encrypted, it wouldn't have been a problem. > Sure, anything sensitive should be encrypted before it goes over > that infrastructure. But I'm sure some large equipment vendor was > lobbying somewhere. >> >> Mandating privacy on HTTP will make it easier in some cases >> (e.g. infrastructure) to eavesdrop on non-private communication. >> >> >> What? Mandating privacy makes it easier to eavesdrop? I don't >> think so :-) > sure it does. How can you tell if something is spyware or > eavesdropping on you if you can't see if the phone home data is a > version check or a report of your activity because it's encrypted? > If my phone-home data is plaintext HTTP, I can demonstrate it's > not eavesdropping. >> >>> 4. Scanning for malware at a gateway. This requirement >>> is NOT going away, and the SSL will be brute-forced / >>> spoofed etc to achieve this. Mandating SSL will just >>> make it easier for malware to propagate, since you make >>> it harder to scan [**]. >>> >>> >>> This problem exists today; IP leakage has to be checked even >>> across TLS based connections. Solutions for these corporate >>> IT groups exist, including TLS aware proxies and TLS man in >>> the middle. Several vendors provide these solutions today. >> Sure. But as previously discussed, the way it is done >> results in an overall reduction in security. A "sanctioned" >> way would be much preferable, but necessarily reduces privacy >> potentially to 0. >> >> >> I disagree that it takes privacy to zero. > I said potentially. If you let your company see your data because > they operate the proxy that terminates the SSL connection from the > browser, then your expectation of privacy (from your company) is > potentially 0. > Companies will continue to insist on scanning or blocking. >> The end user will be aware of such changes; these are only >> possible by changing the trust points in the browser. If your >> company gives you a browser, it can change your trust points. >> But if it is your own browser, you pick the trust points. >> >> I agree this is obscure, but it is something we can improve upon. >> I agree that we should. >> >> Until we turn on SSL for everyone, it won't likely get improved. > Yeah I dunno, I think we could improve it independently of that. >> >> And, do we want shared caches to continue to exist? >> >> >> Of course we do. We switch to opt-in proxies (like what Roberto >> Peon has proposed) rather than the transparent proxies that we >> have today. These are much better because the user has the >> opportunity to know the proxy is there, unlike today. > We've been recommending against using transparent proxying for > years. Unfortunately that doesn't reduce demand for it. > proxy discovery needs to be greatly improved. > But even with explicit proxy use by the client, for SSL/TLS that > just boils down to HTTP CONNECT, which bypasses the proxy anyway. >> Personally, the security risks of using such a proxy probably >> outweigh the performance advantages for most people. > Using a home or corporate proxy has security risks that outweigh > benefits of shared cache and scanning???? > Problem is, the people who operate these proxies think differently > to you. They want to see and scan everything. They don't care so > much about privacy on their LAN. > > > > Aha - this is the crux indeed. This is the advocated position of the > "people that operate these proxies". > > I'm taking the position of the user. I want the user to be able to > know if someone is spying on them in all cases. I think censorship > and alteration of content is such a huge risk to us as a free people > that we simply cannot tolerate not knowing who is scanning our lines. > We must must must know it. > > I have yet to find a single user that wants their communications to be > sniffed and potentially altered by third parties without their > knowledge. Do you want that for your own data? > I had to collate data for a survey on cancer about 11 years ago. Asking essentially a) who *wants* to catch cancer? yes/no/dont-care and b) who regularly sunbathes? yes/no and c) are you aware sunbathing regularly leads to melanoma ? yes/no Here in NZ where (b) leads to (a) at a horrifyingly high % rate. ... nobody said yes to (a). A large group said yes to (b). The same large group mostly said yes to (c)!! These are our typical users .... actively and knowingly going out and reaching toward goals they say they dont want. > Now, I'm not trying to block the proxy operators you mention. I just > want the users to be made aware of their presence, so that users can > decide for themselves whether it is ok (because its their boss on > their company computer) or not (because its someone at my telco). > > We do have a choice here - safety for the users vs. enabling of > transparent snooping for anyone. > > I choose the users 100% of the time. > Mike Would you care to guess how many *years* the proxy community have been trying to send alerts to the user only to be blocked by the Browser agent? I respectfully refer you to: http://www.squid-cache.org/mail-archive/squid-dev/201207/0114.html Note the past paragraph ... we have to MITM the TLS connection then send an error page *inside* the encrypted tunnel. Just to get the *user* to be aware that they are connecting via a proxy that needs login. Even using Marks new status code wasn't enough! Cromium is not alone in this. IE "friendly errors" have also been a long-standing barrier to informing users of anything in under one MTU of data, at least in that battle we had most of the web developer community and even the server communities on our side in that one. Now who was it fighting for user-awareness again? AYJ
Received on Wednesday, 18 July 2012 11:33:21 UTC