Re: Considering the pressure to turn HTTPS into a three-party protocol

On 2/16/2015 1:14 AM, Mark Nottingham wrote:
>> >On 16 Feb 2015, at 4:59 pm, Ryan Sleevi<sleevi@google.com>  wrote:
>> >
>> >The overall topic is that you've presented as "An Issue" for the TAG a
>> >question of how users use and administer their machines, and whether
>> >the TAG should intervene. I'm (hopefully clearly) rather opposed to
>> >this.
> That's a concise statement of the problem, thanks.

I respectfully suggest that's a bit too limited as a framing.

As I said in my earlier note, I think there's a question that arises 
whether or not we are talking specifically about users and their 
configuration of machines & browsers

When an https-scheme URI is dereferenced per the pertinent specifications, 
starting with RFC 3986 [1] and continuing (as discussed in the TAG finding 
on the Self-describing Web [2]) from there to RFC 4395 [3] to RFC 7230 
section 2.7.2 [4], etc.). We find in [4]:

"2.7.2.  https URI Scheme

    The "https" URI scheme is hereby defined for the purpose of minting
    identifiers according to their association with the hierarchical
    namespace governed by a potential HTTP origin server listening to a
    given TCP port for TLS-secured connections ([RFC5246]).

    All of the requirements listed above for the "http" scheme are also
    requirements for the "https" scheme, except that TCP port 443 is the
    default if the port subcomponent is empty or not given, and >>the user
    agent MUST ensure that its connection to the origin server is secured
    through the use of strong encryption, end-to-end, prior to sending
    the first HTTP request.<<" [Emphasis mine...Noah]

I think you can make the case that this REQUIRES unmodified end-to-end 
communication to the origin server. This is not specific to browsers, 
users, or configuration of machines. It's the definition of the https URI 
scheme.

Now, we can also point out that the user agent is, well, the user's agent. 
If a user chooses to modify his/her agent with an extension that does 
something other than what the normative specifications require, the user 
can do that, but hasn't he or she now turned it into something 
non-conforming? Isn't that what's happening when the user (intentionally or 
otherwise), grants permission for an extension, ISP proxy or other means of 
replaying the end-to-end check with MITM?

If we're heading toward a world where the typical Web software, as 
deployed, violates the most fundamental and straightforward of normative 
Web specifications, I think the TAG should have something to say about that.

This seems to me a case where the specifications are pretty clear, and they 
are not fundamentally about user agents. They are about the required 
resolution of an https-scheme identifier, whether by a user agent or 
anything else.

I strongly urge the TAG to consider the question from this perspective, and 
to explain how any conclusions or recommendations reached regarding user 
agents relate to the above referenced normative specifications.

Thank you!

Noah

[1] http://www.ietf.org/rfc/rfc3986.txt
[2] http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html
[3] http://tools.ietf.org/html/rfc4395
[4] http://tools.ietf.org/html/rfc7230

Received on Monday, 16 February 2015 17:36:21 UTC