On 2011/10/03 22:30, Phillip Hallam-Baker wrote:
On Mon, Oct 3, 2011 at 3:29 AM, "Martin J. Dürst"
<[email protected]> wrote:
On 2011/09/30 23:40, [email protected] answered Phillip
Hallam-Baker:
One of the things I was thinking about was that for our case the
essence of the digest is really the digest part. The domain is really
just a location hint. Why stick at just one domain? If the same
content is present at foo.com and bar.com why not have an identifier
that can specify both:
dig:sha-256:wkjfhskjhfskjdhkjdshfjksdkfjhsdkfjh$#=?loc=foo.com&loc=bar.com&ct=text/plain
The example here is a bit more explicit (and doesn't use 'http' as a tag
name), so I'm asking again:
Why isn't this something like:
dig:sha-256:wkjfhskjhfskjdhkjdshfjksdkfjhsdkfjh$#=?loc=http://foo.com/path/to/content.ext&loc=http://bar.com/path/to/content.ext&ct=text/plain
(the slashes here should be %-encoded, but I left them as is for easy
readability)
Now I know that we do not need this for our particular application,
but if we are going to come up with a common scheme with DECADE we
have to meet their use cases as well as out own.
I have some other ideas that would be interesting in the DECADE
context. Right back in 1995 Rohit Khare and myself were fooling about
with identifiers that had decryption keys built in.
For their particular application, the ability to send a single
identifier that allows the content to be uniquely identified,
authenticated and located would be quite interesting I think.
Adding a symmetric decryption key means that the set of people who can
read the plaintext is precisely the set of people with access to the
plaintext plus the people who can access the identifier. The host on
which confidential content resides is thus moved outside the zone
where security concerns apply.
I think I get the idea, but wouldn't that be quite similar to URIs
including passwords? That has been widely frowned upon since quite some
time, to the extent that it has been kicked out from the generic URI
syntax (although it can be quite convenient on occasion).
I note that you have a content type, which I have but someone here was
objecting to. I consider the content type to be essential meta-data
for obvious security reasons.
Our use-case for that is for cases where the named object actually
arrives in some wrapped form (e.g. encrypted) and you need to know
the "inner" content type. However, I could see it being used otherwise
or being dropped as things progress.
Just curious: Why would you need to know the inner content type? Wouldn't
the wrapper contain that information?
Probably so that they can perform negotiation.
If the consumer is a video player, it wants to be able to select
content that it knows how to play. In most cases the player will be
grabbing the bits and negotiating the decryption capability in
parallel.
Ok. I was assuming that the 'outer' content is what's hashed, but it
looks like the outer wrapping (compression or so) is only used on
transport, and it's the 'inner' content that's hashed. Then that makes
sense (using a digest of the outer content but having the content type
apply to the inner content would be quite weird in my opinion).
In my case the concern is that it should be possible to use the
generalized form of this identifier as a secure URL for referencing
static content from a secure Web page.
So imagine that we have anybank.com that has its main pages on HTTPS
but has the images etc. on a separate server that really does not need
SSL for any purpose other than authenticating the source.
It would be a trivial matter to write a script that could transform
such Web pages into Web pages with 'hardened' URLs of the digest form
being discussed here. This would in turn provide a long term answer to
the problem of efficiently supporting the strict security concerns we
discuss here without the overhead of SSL everywhere.
So e.g. the Anybank logo is not a secret, so it can go over HTTP in the
open, and we don't care about where it comes from (even from a bad guy)
as long as it's the same logo, which we can check with the digest.
The only problem with that being that the content-type is actually a
security sensitive piece of meta-data and manipulation of
content-types is a major attack vector (probably the fastest growing
at the mo).
So, just as a totally hypothetical example, the attacker sends exactly
the same bits, but claims they are image/png instead of image/jpg, and
the user sees something different (e.g. an 'okay' button instead of a
'cancel' button).
For these cases of faking metadata, wouldn't it be better to have some
general way of making the metadata part of the content that is hashed?
Regards, Martin.
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
