- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Mon, 16 Feb 2015 12:41:21 -0500
- To: Mark Nottingham <mnot@mnot.net>
- CC: Ryan Sleevi <sleevi@google.com>, "www-tag@w3.org List" <www-tag@w3.org>
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