Re: HTTP vs. HTTPS (was: Re: Call for Community Feedback: Retiring IETF FTP Service)

[Robert Moskowitz <[e-mail]>]

On 11/17/20 11:57 AM, Peter Saint-Andre wrote:
> On 11/17/20 9:02 AM, Keith Moore wrote:
>> On 11/17/20 10:57 AM, Adam Roach wrote:
>>
>>>> Are those web browsers that are deprecating FTP also deprecating HTTP
>>>> without TLS?
>>>
>>> Yes.
>>>
>>> https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
>>>
>>> https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
>> Wow.  That's incredibly arrogant and shortsighted.  I cannot begin to
>> count, for instance, the number of Internet appliances out there (in
>> both consumer and industrial applications) that have http interfaces but
>> do not support https.
> Keith, you said something similar on the UTA WG list earlier this year
> when we talked about adding a work item to revise BCP 195 in the light
> of TLS 1.3. It would be helpful if you could explain your thinking in
> more detail. Are you concerned that web browsers which eventually
> deprecate HTTP without TLS will make it impossible for people to
> interact with certain deployed Internet appliances? Do note that when
> the time comes such web browsers will provide an escape hatch: they
> won't make it impossible to use HTTP without TLS, but they will force
> the user to make an explicit decision about setting up an unencrypted
> connection. Here again (as with Adam Roach's messages about the IETF's
> FTP service) it's a question of tradeoffs and cost/benefit analysis.
> Because the vast majority of web browsing activity involves interacting
> with sites on the open web, not with Internet appliances, it seems
> reasonable to protect users during such interactions to prevent a wide
> array of attacks and abuses, from password sniffing to eavesdropping to
> tracking and profiling. However, also giving users the ability to
> explicitly choose unencrypted connections in certain special
> circumstances seems to me to strike the right balance.

Changing the behavior of knowing when you have to use encrypt to knowing 
when you can't encrypt is good policy moving forward.  The user 
interaction needs to be simple in such cases.

Not allowing no encryption is bad business.