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

OK, slight modification to my post. I said:

> 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.

The text quoted does mention user agents, but I think the spirit of my note 
is exactly right. The definition of the https scheme requires resolution 
via an >end-to-end< encrypted session to the origin server.

Noah

On 2/16/2015 12:35 PM, Noah Mendelsohn wrote:
>
>
> 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:41:43 UTC