Re: Fwd: A proposal

Hey Mike

if you stop for a minute and think about it.  Why do you think it's the 
proxy/intermediate authors that have the problem with mandatory TLS?

Adrien


------ Original Message ------
From: "Mike Belshe" <mike@belshe.com>
To: "httpbis mailing list" <ietf-http-wg@w3.org>
Sent: 20/11/2013 6:00:22 a.m.
Subject: Fwd: A proposal
>
>On Tue, Nov 19, 2013 at 6:38 AM, Michael Sweet <msweet@apple.com> 
>wrote:
>>Mike,
>>
>>On Nov 19, 2013, at 5:28 AM, Mike Belshe <mike@belshe.com> wrote:
>>>...
>>>I am not sure what the next 10 years will bring.  But I am certain it 
>>>will bring many incidents where we'll be able to look back and say, 
>>>"hmmm... if we had put TLS in HTTP by default, that might not have 
>>>happened."
>>>
>>>People don't die because we did put in TLS.  They only die if we 
>>>don't.
>>
>>I know you are trying to be dramatic here, but I don't think "think of 
>>the children" arguments have any place here.
>>
>>We can say we have an ethical obligation to support greater 
>>confidentiality/third-party privacy in HTTP (whatever version is 
>>used).  We can even say that TLS is one tool for the job that can make 
>>it harder for third parties to casually collect information about a 
>>person that is accessing a particular web site, and increased usage of 
>>https:// for web sites that store and/or provide Personally 
>>Identifying Information (PII) and/or other sensitive information is 
>>both recommended and useful.
>>
>>But to dramatically state that adding TLS will prevent deaths is both 
>>technically inaccurate (TLS is only one piece of a much bigger set of 
>>changes that are needed, and technology is only one tool used by 
>>oppressive regimes)
>
>You mention the answer to this question later - that we just keep 
>raising the bar on security, not solving it.  And TLS would be a key 
>step in raising the bar.  It also happens to be the only one this group 
>controls - we don't have scope over dns, email, and other areas that 
>would need work too.  Does that mean we have to do nothing?
>
>People do die because of unencrypted HTTP.  I'm not sure how many 
>governments have to get caught before you'll agree with this fact.  
>From from Iran to China to the US, this is widespread.
>
>
>>and does not convince me in the least - in fact, if I was a paranoid 
>>person it would have the opposite effect - why are you so focused on 
>>TLS, what have you to gain, etc.
>
>You're welcome to investigate me, I have nothing to gain.  I'm not a 
>proxy writer like most of the anti-TLS people, and have zero 
>investments or ties or obligations to TLS vendors.
>
>>
>>I think it is important to recognize that we *cannot* secure the 
>>Internet, we can only make it harder for "the bad guys" to figure out 
>>what "the good guys" are doing.  But in doing so we also need to 
>>balance security against what "the good guys" need to know to protect 
>>other "good guys" from "the bad guys" (malware filtering, etc.)
>
>You're alluding to something here; but I'm not sure what it is.  TLS 
>does not prevent the good guys from doing anything.  Maybe you think 
>the NSA is the good guys?  :-)
>
>
>>
>>Finally, I think it is a mistake to tie improved 
>>security/confidentiality/privacy to HTTP/2. It will take a while for 
>>ISPs, web sites, browsers, and proxy vendors to properly support 
>>HTTP/2, and everything we have talked about WRT TLS and HTTP/2 (minus 
>>maybe TLS-encrypted message bodies) applies equally to HTTP/1.x.  
>>Clearly there are recommendations that we can make today (best 
>>practices, deployment strategies, etc.) to provide a "safer" web 
>>browsing experience.
>>
>
>Well, it took 15 years to change HTTP/1.1.  It'll likely be 15 years 
>before we change HTTP/2.  So if you say "not now", then the question 
>becomes when?  Because the next likely opportunity is 2025-2030.  
>Recommendations are weak; and having an unsecured mode leads to broken 
>security UIs for which we've all seen the research that shows it 
>doesn't work.  When do we want to get serious about fixing this?
>
>We can design for the past - where it was harder to get TLS going and 
>where middleware proxies served a small role.  Or we can design for the 
>future, where it will continue to get easier and easier to rollout TLS. 
>  And with a little prodding from this group, we can take the tooling to 
>a new level.  And we can fix the biggest issues in  TLS!  But the first 
>step is for us to want it now.
>
>I'm designing for the future. Its not a comprehensive plan, its just 
>the first small step.
>
>Mike
>
>
>>_________________________________________________________
>>Michael Sweet, Senior Printing System Engineer, PWG Chair
>>
>
>