Subject: Re: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-01.txt

From: Bjartur Thorlacius <[email-masked]>
Date: Sun, 29 May 2011 22:48:50 +0000

The current draft specifies that browser hints are a resource
identified by the URI "/.well-known/browser-hints" resolved relative
to an URI scheme, an authority section, and an empty path (assuming I
understand the draft correctly). I believe this to be harmful, as the
URI shares the authority section with other URIs, but is in fact named
by IETF (even though IETF doesn't maintain the resource).
Have you considered the possibility of passing this information as a
response to another method than GET, e.g. OPTIONS?
If creating a new method or reusing OPTIONS isn't an option (no pun
intended), could a new URI scheme be used, so that the hints are still
assigned an URI, without polluting the namespace supposedly given to
domain name registrants, and potentially clashing with existing or
future URIs.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 30 May 2011 22:57:41 +1000

Bjartur,

See RFC 5785.

Cheers,

On 30/05/2011, at 8:48 AM, Bjartur Thorlacius wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham   http://www.mnot.net/

---

From: Bjartur Thorlacius <[email-masked]>
Date: Mon, 30 May 2011 13:49:24 +0000

> See RFC 5785.
RFC 5785 is fine when you're limited to GET and PUT, which is often the 
case. This is not one of them.

 > RFCXXXX * HTTP/1.1
 > Host: example.net

< 200 OK
< Content-Type: example/example
< Content-Location: http://etc.example.net/hints
<
 > {....}

It is also possible to use the authority instead of the asterisk (as per 
RFC 2616). This would have the minor security benefit of not allowing 
users who can register arbitrary path components below the root, as in a 
user registering as ".well-known" and uploading a maliciously named file 
to make clients open insane amounts of connections to the host.
What use cases does this method not fulfill?

---

From: Julian Reschke <[email-masked]>
Date: Mon, 30 May 2011 16:58:07 +0200

> case. This is not one of them.

How is this limited to specific methods?

> What use cases does this method not fulfill?

It appears you're trying to re-open an old discussion about how to 
expose server-wide metadata. Been there, done that. RFC 5785 is what 
came out of it.

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 30 May 2011 18:04:16 +0300

> domain name registrants, and potentially clashing with existing or
Bjartur, just my personal opinion.

/.well-known/ has been designed specially to allow everybody and 
everything (meaning applications) to know that something is exactly 
there, and not anywhere else.  Using GET with the definite well-known 
path, denoted as defined in RFC 5785, is probably the easiest way to 
provide a means of access to some particular pre-defined resource in 
HTTP.  I don't understand why we should create a new HTTP method (as you 
proposed in your subsequent message) or a new URI scheme (as you propose 
above) and, in this way, complicate the "protocol", if it may be called so.

What is currently proposed by Mark is fine and needs no further 
improvements (with respect to how the hints are discovered).

Mykyta Yevstifeyev

---

From: Bjartur Thorlacius <[email-masked]>
Date: Mon, 30 May 2011 16:25:12 +0000

> How is this limited to specific methods?
It isn't. Well known locations are simply the best way to discover 
server-wide metadata when all you have is GET.
> expose server-wide metadata. Been there, done that. RFC 5785 is what 
I'll have to read the discussions behind RFC 5785. I seem to vastly 
underestimate the deployment difficulties of a new method.
> Rather, they are designed to facilitate
>     discovery of information on a site when it isn't practical to use
>     other mechanisms;
In other words well known locations are a hack. RFC 5785 mitigates most 
of the drawbacks of the hack, by providing a common prefix for future 
well known locations, but it's still misusing GET. It breaks breaks the 
hierarchical nature of the hierarchical part of URIs. This problem gets 
worse for every new well known location. What are the implications of an 
attacker forging max-conns? The value of the property would be lessened 
if user agents imposed strict limits on the value.

> and attacks where limited access to a server grants the ability to
>     affect how well-known URIs are served.

---

From: MyKyta Yevstifeyev <[email-masked]>
Date: Mon, 30 May 2011 20:58:34 +0300

30.05.2011 16:49, Bjartur Thorlacius wrote:
> RFC 5785 is fine when you're limited to GET and PUT, which is often 
> the case. This is not one of them.
BTW, RFC 5785 works with standard 'http' URIs which imply the GET 
method, not PUT or anything else.  Unless we decide to use other method 
(which is very unlikely to happen), well-known URIs are fine.

Mykyta Yevstifeyev
> [ . . . ]

---

From: Dzonatas Sol <[email-masked]>
Date: Mon, 30 May 2011 11:01:42 -0700

On 05/30/2011 09:25 AM, Bjartur Thorlacius wrote:
> In other words well known locations are a hack. RFC 5785 mitigates 
> most of the drawbacks of the hack, by providing a common prefix for 
> future well known locations, but it's still misusing GET. It breaks 
> breaks the hierarchical nature of the hierarchical part of URIs. This 
> problem gets worse for every new well known location. What are the 
> implications of an attacker forging max-conns? The value of the 
> property would be lessened if user agents imposed strict limits on the 
> value.

People often implement the ReSTful paradigm based only on these four 
http methods: POST, GET, PUT, DELETE. I hardly consider usage of those 
to the fullest means as any hack. (In my book. they each are subclasses 
of TASKs on the queue.)

Any implication of an attacker... questionable on why would one stop 
there, specifically, even if we assume "they're inside".

Personally, I see /.well-known/ as simple as file based implementation, 
yet obviously much more can be done with the flexibility of logical 
devices. In the simple form GET is available. With logical devices (or 
permissions) one can implement the other 3 methods and negotiate options.

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

---

From: Bjartur Thorlacius <[email-masked]>
Date: Mon, 30 May 2011 23:25:42 +0000

> to the fullest means as any hack. (In my book. they each are subclasses
I consider creating URIs under all URI authorities (as in the
authority section of the hierarchical part) questionable, not the
usage of an existing method. Why should the IETF construct URIs such
as <http://boards.4chan.org/.well-known/browser-hints> and
<URL:http://www.gov.cn/.well-known/browser-hints>. There's no image
board named ".well-known". It's /possible/ to use RFC 5785 for _all_
site-wide metadata, no matter what, just as it's /possible/ to use
POST to it's fullest, and POST exclusively, embedding the action and
entity-body in the message-body.
What queue? Most (but not all) HTTP methods operate on resources
identified by URIs.

> there, specifically, even if we assume "they're inside".
You don't necessarily have to be "inside" to be able to upload files.
I'm thinking of a user registering as ".well-known" and uploading
maliciously named and crafted files. *All* HTTP servers out there will
have to reserve the "/.well-known" prefix, if only to avoid serving a
dangerous value of the max-conns property in the browser-hints file
(and thereby values of other properties such as max-pipeline-depth).

Note that I don't disagree with RFC 5785. It's the right mechanism for
certain tasks. I disagree with the apparent group consensus that
discovery of browser hints are one of these tasks.

---

From: Dzonatas Sol <[email-masked]>
Date: Mon, 30 May 2011 17:27:42 -0700

> What queue? Most (but not all) HTTP methods operate on resources

We don't inline any of the http method calls, so they are all queued 
asynchronously. Programs, then, can easily examine the queue for 
optimizations, especially to stream them all together. That's the 
ReSTful queue. That's works well and simply quicker when there hundreds 
of queries between two end points.

> maliciously named and crafted files.

If someone is not logged in, for example, then one could issue one of 
the 3xx codes and possibly issue some private URL. I don't see the 
conflict there.

>   *All* HTTP servers out there will

"have-to"?

The example uses the full path for simple conveyance, yet there could be 
</.well-known/> in container setups that implement RFC5785 and 
<draft-nottingham-http-browser-hints-01.txt/>, especially when 
restricted to no nested directories. If there is no </.well-known/> then 
most likely fallback to the "User-Agent:" header if that exists; 
otherwise, eventually assume some past http provider on one end.

> discovery of browser hints are one of these tasks.

Do you think that information should exist in the "User-Agent:" header 
and have everybody upgrade their browser together as one group? Maybe 
some rather use 'cloud' containers with restricted data driven flow, but 
I can think of too many other examples, and the 'cloud' idea is actually 
useful for an example as one step beyond as site (i.e. containers) on 
demand despite paths based on URIs in individual queries and synchronous 
end-to-end flow.

--

---

From: Bjartur Thorlacius <[email-masked]>
Date: Wed, 1 Jun 2011 02:44:20 +0000

> of queries between two end points.
I thought responses to pipelined requests had to be returned in order,
breaking most optimization opportunities. I seam to be
misunderstanding something.

> the 3xx codes and possibly issue some private URL. I don't see the
We seem to misunderstand each other. I'm thinking of a hypothetical
server set up prior to RFC 5785 that allows users to choose the path
component of URIs for files they upload. On that server
/.well-known/browser-hints could refer to user content, yielding
terror.

>> (and thereby values of other properties such as max-pipeline-depth).
Yes, so they don't let /.well-known/browser-hints refer to anything
else. There's hardly any risk of that happening accidentally, but it's
uncomfortably easy to plant a malicious browser-hints file at the
right location. It's common for multiple users to share a domain by
allocating one path component directly below root to each user as a
prefix. I can't think of a registry that accepts registrations from
untrusted users, but they surely exisy. Information under one prefix
shouldn't affect the server's stability.
Maybe this'll be less dangerous when I've slept some.

> otherwise, eventually assume some past http provider on one end.
If there is no /.well-known/* then there's no problem. But as soon as
there is, browser may start interpreting it. I don't see what the
User-Agent header has to do with anything; User-Agent provides
information to servers, while browser-hints provide recommendations to
browsers.

> demand despite paths based on URIs in individual queries and synchronous
You've lost me; there too many ideas in this paragraph for me to
comprehend at once. I'm not proposing adding any information to the
User-Agent header. From my point of view User-Agent is motly there for
backwards compatibility and telling the world how esotoric software
you use. There isn't any useful information therein.

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 31 May 2011 22:28:12 -0700

The existence of the "User-Agent:" proves that someone wanted that 
there, so from backwards compatibility, the process flow I wrote with 
the two "CONNECT /000" happens before any "User-Agent:" field exists.

first-hand: the state does not exist.
second-hand: the state existed or exists.

One intent is for stateful transfers with the ReSTful paradigm (this is 
simpler). The HTTP is there in the hypermedia (the two "CONNECT /000" 
given) in stream mode by "Content-Type:" multi-parts. We found we can't 
do stateful transfers with SSL without consistent major 
reimplementation, over and over through the years. I proved earlier (the 
flow format) how S/MIME can help solve that (if my expression is seen as 
one template of stateful transfers).

I'm just one scientist with lots of results. Some are useful and some 
are useless, and we don't have ordinary time to explain them all. I 
think you found something useful (to solve this further) even if neither 
of us has stated such specifically.

--