-Original Message-
From: Thomas Roessler [mailto:t...@w3.org]
Sent: Tuesday, February 10, 2009 5:06 PM
BTW, I notice that this draft is silent on the HTTP header syntax's
combining feature for multiple occurences of the same field (last
paragraph of 4.2, RFC 2616); I suspect that
On Tue, Feb 10, 2009 at 4:31 PM, Mark Nottingham m...@yahoo-inc.com wrote:
Well, the authority is host + port; common sense tells us that it's unlikely
that the same (host, port) tuple that we speak HTTP on is also going to
support SMTP or XMPP. I'm not saying that common sense is universal,
On Tue, Feb 10, 2009 at 11:51 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
In particular, you should require that
the host-meta file should be served with a specific mime type (ignore
the response if the mime type is wrong. This protects servers that
let users upload content from having
On Tue, Feb 10, 2009 at 11:37 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
First, scheme is incorrect here as the scheme does not always determine a
specific protocol
(see 'http' is not just for HTTP saga).
I don't understand this level of pedantry, but if you want host-meta
to be usable
On Wed, Feb 11, 2009 at 10:14 AM, Adam Barth w...@adambarth.com wrote:
Adobe found the security case compelling enough to break backwards
compatibility in their crossdomain.xml policy file system to enforce
this requirement. Most serious Web sites opt-in to requiring an
explicit
How about clearly identifying the threat in the spec instead of making this a
requirement?
EHL
On 2/11/09 10:14 AM, Adam Barth w...@adambarth.com wrote:
On Tue, Feb 10, 2009 at 11:51 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
In particular, you should require that
the host-meta file
Your approach is wrong. Host-meta should not be trying to address such security
concerns. Applications making use of it should. There are plenty of
applications where no one care about security. Obviously, crossdomain.xml needs
to be secure, since, well, it is all about that. But copyright
I don't care of this level of pedantry which is why I don't want to use terms
that people have a problem agreeing what it means.
There is nothing incorrect about: GET mailto:j...@example.com HTTP/1.1
It might look funny to most people but it is perfectly valid. The protocol is
HTTP, the scheme
That would cause interoperability problems where user agents that care
about security would be incompatible with sites implemented with
insecure user agents in mind. Based on past history, this leads to a
race to the bottom where no user agents can be both popular and
secure.
On Wed, Feb 11,
On Wed, Feb 11, 2009 at 11:52 AM, Eran Hammer-Lahav e...@hueniverse.com wrote:
Your approach is wrong. Host-meta should not be trying to address such
security concerns.
Ignoring security problems doesn't make them go away. It just means
you'll have to pay the piper more later.
Applications
On Wed, Feb 11, 2009 at 11:55 AM, Eran Hammer-Lahav e...@hueniverse.com wrote:
There is nothing incorrect about: GET mailto:j...@example.com HTTP/1.1
I don't know how to get a Web browser to generate such a request, so I
am unable to assess its security implications.
It might look funny to
I have to say that the current known use-cases for site-meta are:
1. Security critical ones, but for server-to-server discovery uses (not
browser mediated)
2. Semantic ones, for user consumption, of an informative rather than
security-critical nature. These use cases may be handled by browsers.
On Wed, Feb 11, 2009 at 1:04 PM, Breno de Medeiros br...@google.com wrote:
I have to say that the current known use-cases for site-meta are:
1. Security critical ones, but for server-to-server discovery uses (not
browser mediated)
2. Semantic ones, for user consumption, of an informative
On Wed, Feb 11, 2009 at 1:26 PM, Adam Barth w...@adambarth.com wrote:
On Wed, Feb 11, 2009 at 1:04 PM, Breno de Medeiros br...@google.com
wrote:
I have to say that the current known use-cases for site-meta are:
1. Security critical ones, but for server-to-server discovery uses (not
On Wed, Feb 11, 2009 at 1:46 PM, Breno de Medeiros br...@google.com wrote:
The current proposal for host-meta addresses some use cases that today
simply _cannot_ be addressed without it.
I'm not familiar our process for adopting new use cases, but let's
think more carefully about one of the
On Wed, Feb 11, 2009 at 2:01 PM, Adam Barth w...@adambarth.com wrote:
On Wed, Feb 11, 2009 at 1:46 PM, Breno de Medeiros br...@google.com
wrote:
The current proposal for host-meta addresses some use cases that today
simply _cannot_ be addressed without it.
I'm not familiar our process for
But you are missing the entire application layer here! A browser will not use
host-meta. It will use an application spec that will use host-meta and that
application, it security is a concern, will specify such requirements to ensure
interoperability. It is not the job of host-meta to tell
On Wed, Feb 11, 2009 at 2:15 PM, Breno de Medeiros br...@google.com wrote:
1. The mechanism is not sufficient strong to prevent against defacing
attacks.
We're not worried about defacement attacks. We're worried about Web
servers that explicitly allow their users to upload content. For
On Wed, Feb 11, 2009 at 2:26 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
But you are missing the entire application layer here! A browser will not
use host-meta. It will use an application spec that will use host-meta and
that application, it security is a concern, will specify such
On 2/11/09 12:38 PM, Adam Barth w...@adambarth.com wrote:
On Wed, Feb 11, 2009 at 11:55 AM, Eran Hammer-Lahav e...@hueniverse.com
wrote:
There is nothing incorrect about: GET mailto:j...@example.com HTTP/1.1
I don't know how to get a Web browser to generate such a request, so I
am unable
On Wed, Feb 11, 2009 at 2:36 PM, Adam Barth w...@adambarth.com wrote:
On Wed, Feb 11, 2009 at 2:15 PM, Breno de Medeiros br...@google.com
wrote:
1. The mechanism is not sufficient strong to prevent against defacing
attacks.
We're not worried about defacement attacks. We're worried about
On Wed, Feb 11, 2009 at 2:44 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
You got this backwards.
Ah. Thanks for this response. I understand the situation much better now.
Let me see if I understand this correctly for the case of the https scheme.
1. You want to find out more about
On Wed, Feb 11, 2009 at 2:46 PM, Breno de Medeiros br...@google.com wrote:
However, such applications could handle
specifying content-type as a requirement, as Eran rightly pointed out.
Why force everyone interested in use case (1) to add this requirement?
This will have two results:
1) Some
On Wed, Feb 11, 2009 at 3:22 PM, Adam Barth w...@adambarth.com wrote:
On Wed, Feb 11, 2009 at 2:46 PM, Breno de Medeiros br...@google.com
wrote:
However, such applications could handle
specifying content-type as a requirement, as Eran rightly pointed out.
Why force everyone interested in
On Wed, Feb 11, 2009 at 3:32 PM, Breno de Medeiros br...@google.com wrote:
In that case, content-type is a mild defense. Can you give me an example
where a web-site administrator will allow files to be hosted at '/'?
There are enough of these sites to force Adobe to break backwards
On Wed, Feb 11, 2009 at 3:57 PM, Adam Barth w...@adambarth.com wrote:
On Wed, Feb 11, 2009 at 3:32 PM, Breno de Medeiros br...@google.com
wrote:
In that case, content-type is a mild defense. Can you give me an example
where a web-site administrator will allow files to be hosted at '/'?
On Wed, Feb 11, 2009 at 3:57 PM, Adam Barth w...@adambarth.com wrote:
On Wed, Feb 11, 2009 at 3:32 PM, Breno de Medeiros br...@google.com
wrote:
In that case, content-type is a mild defense. Can you give me an example
where a web-site administrator will allow files to be hosted at '/'?
On Wed, Feb 11, 2009 at 4:00 PM, Breno de Medeiros br...@google.com wrote:
All of the above systems target browsers and none have the usage
requirements of the proposed spec.
The point is there are enough HTTP servers on the Internet that let
uses upload content in this way that these vendors
On Wed, Feb 11, 2009 at 4:38 PM, Adam Barth w...@adambarth.com wrote:
On Wed, Feb 11, 2009 at 4:00 PM, Breno de Medeiros br...@google.com
wrote:
All of the above systems target browsers and none have the usage
requirements of the proposed spec.
The point is there are enough HTTP servers
On Wed, Feb 11, 2009 at 4:40 PM, Breno de Medeiros br...@google.com wrote:
Yes, but your solution prevents legitimate use cases that are a higher value
proposition.
How does:
On Wed, Feb 11, 2009 at 3:22 PM, Adam Barth w...@adambarth.com wrote:
2) Add a section to Security Considerations
On Wed, 11 Feb 2009, Breno de Medeiros wrote:
2. This technique may prevent legitimate uses of the spec by
developers who do not have the ability to set the appropriate
header.
Many developers can control Content-Type headers using .htaccess files
(and their ilk).
And many
On Wed, Feb 11, 2009 at 5:00 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 11 Feb 2009, Breno de Medeiros wrote:
2. This technique may prevent legitimate uses of the spec by
developers who do not have the ability to set the appropriate
header.
Many developers can control
On Wed, 11 Feb 2009, Breno de Medeiros wrote:
On Wed, Feb 11, 2009 at 5:00 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 11 Feb 2009, Breno de Medeiros wrote:
2. This technique may prevent legitimate uses of the spec by
developers who do not have the ability to set the
On Wed, Feb 11, 2009 at 5:25 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 11 Feb 2009, Breno de Medeiros wrote:
On Wed, Feb 11, 2009 at 5:00 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 11 Feb 2009, Breno de Medeiros wrote:
2. This technique may prevent legitimate uses of the
On Wed, 11 Feb 2009, Breno de Medeiros wrote:
My only concern is that the requirement is construed as reasonably
sufficient for security (which is indeed the case of crossdomain.xml,
but not for many intended applications). The example Adam just gave,
i.e., server-to-server
So the proposal is for a security considerations section that describes
attending threats and strongly hint that applications will be vulnerable if
they do not adopt techniques to validate the results. It would suggest the
use of content-type headers and explain what types of threats it protects
On Wed, Feb 11, 2009 at 6:04 PM, Breno de Medeiros br...@google.com wrote:
So the proposal is for a security considerations section that describes
attending threats and strongly hint that applications will be vulnerable if
they do not adopt techniques to validate the results. It would suggest
37 matches
Mail list logo
