gmane.org.w3c.uri

Re: URI Templates update

Mark Nottingham — 2012-05-18T00:43:17

On 17/05/2012, at 10:03 PM, Joe Gregorio wrote:


Ah, I just did some packaging, QA and bug-hunting; the code's all yours :) 

Cheers,


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

Re: URI Templates update

Joe Gregorio — 2012-05-17T12:03:06

Who's this "we" you speak of? Mark did all the work, for which I'm
very grateful! Thanks Mark!

  -joe

URI Templates update

Mark Nottingham — 2012-05-17T11:28:11

Hi URI people,

Just a few notes regarding URI Templates, since we have an RFC now <http://tools.ietf.org/html/rfc6570>:

* Joe's implementation in Python has been moved to Github, and we've got it up to RFC level 4 conformance. See <https://github.com/uri-templates/uritemplate-py>. It's also now listed in pypi <http://pypi.python.org/pypi/uritemplate/0.5.1>. Note that it's still beta-quality; it doesn't do much in the way of input checking, for example.

* We've also started collecting test cases at <https://github.com/uri-templates/uritemplate-test>. Right now it includes the examples from the RFC, but we've been talking with other implementers about adding more; please make a pull request or raise an issue as appropriate. Note that the Python implementation above uses these for its testing.

* Finally, the list of implementations at <http://code.google.com/p/uri-templates/wiki/Implementations> has been updated. If you have more information about one of them, or would like one added, please make a comment

Re: URI Template spec has been approved

Marc Portier — 2012-03-25T08:58:52

Hi Roy,

I finally got round to cleaning up on the js implementation.
Transition from 0.7 to 0.8 was rather uneventful :)
https://github.com/marc-portier/uri-templates/commit/8fb3411d25a3d6082eb3fa966eedd365df6e0bc9

I'ld appreciate if you could make a reference to the
https://github.com/marc-portier/uri-templates (javascript
implementation) over at:
http://code.google.com/p/uri-templates/wiki/Implementations

I've also put up a simplified syntax-diagram (railroad based on the ebnf
from the spec) up on the wiki:
https://github.com/marc-portier/uri-templates/wiki

(generated through https://github.com/marc-portier/ebnfdiagram)

kind regards,
-marc=


2012/2/4 Roy T. Fielding <fielding< at >gbiv.com>

Re: http+aes

Carsten Bormann — 2012-03-08T06:58:05


"Cleverly" misusing existing elements of existing (deprecated in certain contexts) syntax is not necessarily better than introducing new syntax.  (And what I proposed isn't that new either, but the specific syntax wasn't the point anyway.  The clean nesting was.)

The "500" problem can easily be solved by specifying the post-frobnicating such that it only applies to the body of 200 (and 206!) responses.  (For 206, the post-frob spec will of course have to explain how that works, but that's obvious for CTR and byte-ranges.  And, also obviously, partials plus thatcherizing give you great watermarking as well.)

I'm still not convinced that I like this approach a lot for the problem it is trying to solve, but I'm a bit taken back by the many responses that it does not solve other problems it is not trying to solve.  Clearly, the applicability must be well-documented (together with the actual details of the algorithm), which is good reason to put the actual post-frob spec into a different place than the HTML s

RE: http+aes

Michael Wojcik — 2012-03-07T17:15:41

It's similar, yes, and also similar to various proposed "Birthday
Paradox" attacks against digital signatures using too-short digests
(where you vary whitespace until you produce an image collision), etc.
The real idea here, though, is that rather than giving every user a
unique key, you partition the keyspace for each resource, so an
accumulation of leaked keys gives increasing probabilistic
identification of the source of the leak.


Of course not - I meant it as an argument *against* http+aes. That's why
I wrote "potentially worse" above.

Re: http+aes

Poul-Henning Kamp — 2012-03-07T16:32:49

In message <0AB4526732901E45B9B3A55FFD725D67019CBB16< at >AUS-EXCHANGE.microfocus.co
m>, "Michael Wojcik" writes:


What you propose is what's called "Thatcherizing" a document: During
the Thatchers government, they tweaked the spacing in a confidential
memo so that each recipients copy were unique, in order to expose
who leaked it to the press.

It is however, not an argument for the circus-crypto og http+aes

RE: http+aes

Michael Wojcik — 2012-03-07T15:13:08

Actually, I think it's potentially worse than that. Consider this case:

- Publisher puts 100 copies of each resource on CDN, each encrypted with
a different key.
- When a registered user requests a copy of a resource from Publisher,
they're given one of the hundred keys, chosen at random; Publisher
records this {user,resource,key} tuple.
- As {resource,key} pairs are leaked, publisher can make a probablisitic
argument about which users are leaking keys. For a single {resource,key}
pair, publisher has already narrowed the search down to one percent of
the users who requested that resource.
- If a relatively small number of the keys for a given resource are ever
leaked, and some users are much more prolific leakers than others,
publisher can identify those "evil users" with good probability.

This potentially gives publishers a way to make probabilistic arguments
for pushing liability onto their customers (surprise!), at a 100x (or
whatever N a publisher thinks will be optimal) increase in storage
costs. And

RE: http+aes

Manger, James H — 2012-03-07T01:48:46

Ian,



This is not the security you get. It does make it more awkward for a rogue CDN employee to get the content of, say, a movie. He cannot just copy the file from a disk in the CDN. But the rogue CDN employee can still copy the movie by tinkering with one response to one user. [For instance, replace a known part of the movie (eg common header) with malware that returns the key (XOR the ciphertext with the known-part (exposing that part of the keystream) then XOR with the malware).]



I totally disagree. If the rogue employee damages all the content (so it no longer works) to all users all the time then the CDN will lose its business pretty quickly. However, the attack can be against individual users and it doesn't even need to disrupt the movie (the inserted malware can expose the key and continue playing the movie).



A URL hack (eg key material in the userinfo field); http hacks (body no longer matches content-type header; errors screwed up; redirects break); a crypto hack (encryption without integri

Re: http+aes

Henrik Nordström — 2012-03-07T01:49:15

mån 2012-03-05 klockan 23:29 +0000 skrev Ian Hickson:


Depends on the CDN model. Any CDN seeded by fetching content over HTTP
from some master server should do fine.

Content-Encoding is a property of the object injected into the CDN.


why do same-origin pose a problem?

You mean because the plugin can not fetch http://some.other.domain/key?

Just provide the key information in whatever references the encrypted
URL. Hinting a keyid in the encrypted resource response is not really
needed, it's sufficient to say that it's encrypted.

Regards
Henrik

RE: http+aes

Ian Hickson — 2012-03-07T00:23:45

The security that we expect here is exclusively that an untrusted CDN 
can't copy the data. As far as I can tell, this is indeed the security 
provided by this proposal.

The use case is specifically one that assumes that the attacker, in this 
case the untrusted CDN, is not in a position to damage the content.

This seems like a very reasonable assumption. If you provide a CDN 
service, and you corrupt data that you serve, you're likely to lose your 
business. It's not like you can blame anyone else for it. However, if 
content that you host happens to also turn up elsewhere on the net, then 
there's really nothing to trace the problem back to you.

(My assumption is that really what we're not trusting here isn't so much 
the CDN as a whole, as much as rogue employees within the CDN who might 
want to go and harvest files being cached there.)



Certainly damaging the content can occur, but it isn't what we're trying 
to protect against here.

There are other cases (e.g. distributed hosting for FTP sites)

Fw: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt

t.petch — 2012-03-06T15:38:06

For those with an interest in the ABNFing of URI who have not seen this on the
IETF uri-review or on ipv6 lists, the question is how to tack an ipv6 zoneid
onto the constructs in RFC3986, while preserving the long standing ipv6 practice
of using a percent character as the separator in this case.

I would suggest follow-up on one of the two afore mentioned lists.

Tom Petch

----- Original Message -----
From: "Bill Fenner" <fenner< at >fenron.net>
To: "Brian E Carpenter" <brian.e.carpenter< at >gmail.com>
Cc: <ipv6< at >ietf.org>; "Brian Haberman" <brian< at >innovationslab.net>; "S Moonesamy"
<sm+ietf< at >elandsys.com>; <ipv6-chairs< at >tools.ietf.org>
Sent: Tuesday, March 06, 2012 1:08 PM
Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt


On Mon, Mar 5, 2012 at 7:15 PM, Brian E Carpenter
<brian.e.carpenter< at >gmail.com> wrote:
ways).

Previous joint work between the ipv6 working group and the W3C URI
working group resulted in a decision that did not change the ABNF at
all, in 2 ways:

1. It used the IPvFuture extension m

Re: http+aes

Anne van Kesteren — 2012-03-06T08:25:42

How? A resource on server S links to a resource on CDN C using http+aes.  
C's resource is encrypted. C does not know the key. The key is hosted on  
S's resource as part of the http+aes link. When the user agent fetches C's  
resource it does not include the key, but decrypts it as data comes in. So  
C never knows anything about the bits it is hosting, S and the user agent  
do.

Re: http+aes

Ian Hickson — 2012-03-06T06:40:09

That's just how we roll in the HTML world these days.

Re: http+aes

Eric J. Bowman — 2012-03-06T05:51:10

Which makes me even more frustrated with the process being followed.
Surely the idea is more than 96 hours old, but what business does
anything conceived of in February have showing up in spec language come
March?  Doesn't feel like standardization, feels like greenfield
development, when the solution shows up before anyone's aware there's a
use case illustrating a problem.

Is the solution based on any interoperable code?  Did that code exist
in the wild, as an ad-hoc solution to the problem, or was it created
after the spec language was drafted?

-Eric

Re: http+aes

Ian Hickson — 2012-03-06T05:04:48

Dude, the proposal is about 96 hours old, cut us some slack.

Re: http+aes

Eric J. Bowman — 2012-03-06T04:21:20

Exactly the last place I'd expect to find new URI schemes a-spawning.
It shouldn't fall to Julian to surface this to the correct group, after
the fact.  The system only fails when it's subverted, which is a shame.

-Eric

RE: http+aes

Manger, James H — 2012-03-06T04:07:31

RE: http+aes <http://dev.w3.org/html5/spec/iana.html#http-aes-scheme>

A URL scheme that combines an address plus key material for securing the content at that address has some merit. http+aes, however, has some specific flaws:

1. Encryption without integrity (as http+aes delivers) is almost worthless. It rarely delivers the security that you expect.
The untrusted CDN can make all sorts of modifications: truncating the content; toggling any bits of the content; etc. Many modifications will cause errors that depend on the content. Watch which errors occur from which modifications and you learn the content. These sorts of practical attacks have occurred numerous times (often with CBC mode, but decrypting without checking integrity is the root cause).

2. Hardwiring 1 specific algorithm (AES), 1 mode (counter), and 3 key lengths (128-bit, 192-bit, & 256-bit) is very poor practise. We need algorithm agility to cope with advances in crypto.

3. What happens if the CDN returns an HTTP redirect? Is the co

Re: http+aes

Ian Hickson — 2012-03-06T04:06:29

W3C HTML working group and #whatwg IRC channel on Freenode.

Re: http+aes

Eric J. Bowman — 2012-03-06T03:07:18

Who is "we" and where are these conversations archived?  I'm feeling
blindsided again, by yet another URI scheme proposal popping up in the
HTML 5 spec.  Without, say, having been floated as an I-D first with the
rationale posted to, say, uri< at >w3.org -- where it wouldn't have escaped
my notice.  That's the accepted, open way, where nobody in the
community feels left out...

Otherwise, it seems like the solution was created first, with the
rationale evolving later, to counter the criticism.  I wouldn't feel
that way if the URI community had discussed it *before* it popped up
in the spec, as a fait accompli you're only interested in _clarifying_
rather than actually entertaining alternative ideas "we" apparently
already considered and rejected...

-Eric

Re: http+aes

Ian Hickson — 2012-03-06T01:26:26

It's not intended that users even know this is being used, so it doesn't 
really matter if they don't understand it.



This is not intended for a situation where you do not trust the 
recipients, indeed. There's not really any credible way to give someone 
content that isn't watermarked in some way if you don't trust them. If the 
content _is_ watermarked, then you probably can't usefully cache it in a 
CDN. If you can, then you can do so with this mechanism as well, it's an 
orthogonal concern.



Let's be honest, most users have no idea what crypto is, let alone that it 
is there. Even things as critical as TLS as used for HTTPS -- most users 
don't really know what's going on. If we're going to rely on users 
understanding crypto, we might as well give up now.



In practice, a CDN would not keep its business if it was damaging the 
content it was caching. This is a substantially different risk than the 
CDN (or a rogue agent within the CDN) just copying the content.

There's no reason this mechanism co