Subject: http+aes

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Mar 2012 11:21:06 +0100

FYI:

	http://dev.w3.org/html5/spec/Overview.html#http-aes-scheme

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 05 Mar 2012 10:29:01 +0000

>	http://dev.w3.org/html5/spec/Overview.html#http-aes-scheme

So you encrypt the response body with the password clearly visible in the
request, to gain privacy ?

Please explain what I'm overlooking here...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Mar 2012 11:34:34 +0100

On 2012-03-05 11:29, Poul-Henning Kamp wrote:
> In message<[email-masked]>, Julian Reschke writes:
>
>> FYI:
>>

Dunno; just forwarding.

You may want to send feedback to the HTML WG mailing list...

Best regards, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Mon, 05 Mar 2012 11:34:27 +0100

> Please explain what I'm overlooking here...

I think the intent is that the user agent does the decryption and that  
therefore the key is not part of the request, but the specification is  
sort of vague / wrong on that it seems. Ian?

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 5 Mar 2012 11:40:04 +0100

> sort of vague / wrong on that it seems. Ian?

Being able to encrypt only the payload would be extremely useful in
server-to-server communications in datacenters. However it's not clear
to me either how this is supposed to be used, especially in requests
to origin servers that lack the scheme.

Regards,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 05 Mar 2012 10:43:14 +0000

In message <[email-masked]>, Willy Tarreau writes:

>server-to-server communications in datacenters.

How usefull is it, when packet sniffing gets you both the key
and the encrypted data ?

I could understand it if the userinfo pointed to a PSK, but sending
the actual AES key as part of the request defeats any attempt at
privacy I can see ?

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Mar 2012 11:51:03 +0100

On 2012-03-05 11:43, Poul-Henning Kamp wrote:
> In message<[email-masked]>, Willy Tarreau writes:
>

I think the confusion comes from embedding local information into the 
URI; it seems the userinfo is not supposed to be transmitted on the 
wire. (which of course raises the question about why it's in the URI then)

Best regards, Julian

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 5 Mar 2012 11:52:57 +0100

> the actual AES key as part of the request defeats any attempt at

I assume the intention is to omit the userinfo in the request, as
it is done with the userinfo in the standard http scheme.

It would be interesting to hear more about the intended use scenario.
My gut feeling is that URIs are public by nature and like to be written
down.

Also, would the fragment identifier, given that a new scheme is introduced
anyway, not be a better place to store information for the client?

Cheers,

Stefan

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Mar 2012 12:02:19 +0100

On 2012-03-05 11:52, Stefan Eissing wrote:
> ...

-1; fragment identifier semantics depends on media type, not protocol...

But yes, it's not entirely clear why this needs to be in the URI.

---

From: "Anne van Kesteren" <[email-masked]>
Date: Mon, 05 Mar 2012 12:08:08 +0100

On Mon, 05 Mar 2012 12:02:19 +0100, Julian Reschke <[email-masked]>  
wrote:
> But yes, it's not entirely clear why this needs to be in the URL.

If you don't tie it to the URL, you will have to change every API (<a>,  
XMLHttpRequest, <video>, <script>, ...) to also take a key.

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 5 Mar 2012 12:14:00 +0100

So the gist of http+aes is to URL-inject a Transfer-Encoding into the
existing http infrastructure?

//Stefan

Am 05.03.2012 um 12:08 schrieb Anne van Kesteren:

> On Mon, 05 Mar 2012 12:02:19 +0100, Julian Reschke <[email-masked]> wrote:
> If you don't tie it to the URL, you will have to change every API (<a>, XMLHttpRequest, <video>, <script>, ...) to also take a key.
> 
> 
> -- 
> Anne van Kesteren

<green/>bytes GmbH

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 5 Mar 2012 12:43:31 +0100

Hi,

> the actual AES key as part of the request defeats any attempt at

I don't know what the intent was there, but my understanding is that
userinfo is a key ID, not the key itself. In enterprise, it's fairly
common to see servers communicate together and indicate to the other
end which key to use (and not the key itself).

Regards,
Willy

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 06 Mar 2012 01:12:02 +1300

> existing http infrastructure?

Content-Encoding, not Transfer-Encoding. Otherwise yes.

Looks like a nifty way to write page URLs for browser-only 
interpretation to me. But no reason why the scheme should be permissible 
or even needed in an HTTP request-URI field.

The use-case presented is secure storage on an untrusted host. Which 
implies that the http+aes:// is mapped to http:// before requesting. The 
+aes and userinfo portions staying internal to the client agent for 
determining only handling of the response. Untrusted host and all other 
infrastructure see just a standard http:// request (no userinfo) with 
opaque binary entity. Ditto for https+aes with equivalent mapping.

AYJ

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Mon, 05 Mar 2012 13:51:03 +0100

> 	http://dev.w3.org/html5/spec/Overview.html#http-aes-scheme

This definition (and the HTTPS+AES one) leaves a lot to be desired, IMO

* What are the use cases?

* Why is it better than using HTTPS? If the URL is sent over HTTPS you  
will very likely already have at least one persistent HTTP connection open  
to the server (assuming it is the same server) so establishing a new  
connection (same or different server) for this request is not going to  
increase performance. Even if no connections are open, for a properly  
configured server, reestablishing a SSL/TLS session is not going to take  
much longer (one extra roundtrip) and the entire request and response will  
be protected.

* What is the keymaterial? If the userinfo is the key, how is it encoded?  
Base64, hex, calculated (how?), or other format, and if so, where is the  
CTR nonce encoded? If userinfo is not the key, how is the userinfo used to  
obtain the the encryption key, and how is that information secured?

* If the keymaterial is intended for long-term usage by a single user,  
depending on storage methods, how is the keymaterial info migrated  
securely to a new client, either for parallel use in multiple clients, or  
system recovery?

* Given that this is probably going to be MITM vulnerable when used over  
plain HTTP, what should the client do if the URL is provided over HTTP (or  
included by reference in a document loaded over HTTP)? Refuse to perform  
the request, or go ahead anyway?

* How does this interact with other ongoing specification work, such as  
the Javascript Crypto APIs?

* How will this interact with clients that does not understand the URL  
scheme? It is quite possible that they will display the userinfo in the  
addressbar or the resulting error messages.

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Mar 2012 14:02:44 +0100

On 2012-03-05 13:51, Yngve Nysaeter Pettersen wrote:
> On Mon, 05 Mar 2012 11:21:06 +0100, Julian Reschke
> <[email-masked]> wrote:
>
>> FYI:
>>

Indeed.

I intended the FYI mail to inform people about what's going on in HTML 
land; not really to have the discussion over here.

I recommend sending feedback to the HTML WG mailing list...

Best regards, Julian

---

From: Karl Dubost <[email-masked]>
Date: Mon, 5 Mar 2012 08:16:42 -0500

> 	http://dev.w3.org/html5/spec/Overview.html#http-aes-scheme

A better link (or less browser killing) ;)
http://dev.w3.org/html5/spec/iana.html#http-aes-scheme

And the text (This is revision 1.5603. Editor's Draft 5 March 2012)

    12.6 http+aes scheme

    This section describes a URL scheme registration for the IANA URI
    scheme registry. [RFC4395]

    URI scheme name:
        http+aes

    Status:
        permanent

    URI scheme syntax:
        Same as http, with the userinfo component instead used for
        specifying the decryption key. (This key is provided in the form
        of 16, 24, or 32 bytes encoded as ASCII and escaped as necessary
        using the URL escape mechanism; it is not in the
        "username:password" form, and the ":" character is not special
        in this component when using this scheme.)

    URI scheme semantics:
        Same as http, except that the message body must be decrypted by
        applying the AES-CTR algorithm using the key specified in the
        URL's userinfo component, after unescaping it from the URL
        syntax to bytes. If there is no such component, or if that
        component, when unescaped from the URL syntax to bytes, does not
        consist of exactly 16, 24, or 32 bytes, then the user agent must
        act as if the resource could not be obtained due to a network
        error, and may report the problem to the user.

    Encoding considerations:
        Same as http, but the userinfo component represents bytes
        encoded using ASCII and the URL escape mechanism.

    Applications/protocols that use this URI scheme name:
        Same as http.

    Interoperability considerations:
        Same as http, but specifically for private resources that are
        hosted by untrusted intermediary servers as in a content
        delivery network.

    Security considerations:

        URLs using this scheme contain sensitive information (the key
        used to decrypt the referenced content) and as such should be
        handled with care, e.g. only sent over TLS-encrypted
        connections, and only sent to users who are authorized to access
        the encrypted content.

        User agents are encouraged to not show the key in user
        interface elements where the URL is displayed: first, it's
        ugly and not useful to the user; and second, it could be
        used to obscure the domain name.

        The http+aes URL scheme only enables the content of a
        particular resource to be encrypted. Any sensitive
        information held in HTTP headers is still transmitted in the
        clear. The length of the resource is still visible. The rate
        at which the data is transmitted is also unobscured. The
        name of the resource is not hidden. If this scheme is used
        to obscure private information, it is important to consider
        how these side channels might leak information.

            For example, the length of a file containing only
            the user's age in seconds encoded in ASCII would
            easily let an attacker watching the network traffic
            or with access to the system hosting the files
            determine if the user was less than 3 years old,
            less than 30 years old, or more than 30 years old,
            just from the length of the file. Padding the file
            to ten digits (either with trailing spaces or
            leading zeros) would make all ages from zero to
            three hundred indistinguishable.

            Another example would be the file name. Consider a
            bank where each user first downloads a "data.json"
            file, which points to some other files for more
            data, such that users in debt download a "debt.json"
            file while users in credit download a "credit.json"
            file. In such a scenario, users can be categorised
            by an attacker watching network traffic or with
            access to the system hosting the files without the
            attacker ever having to decrypt the "data.json"
            files.

        The security considerations that apply to http apply as well.
    Contact:
        Ian Hickson <[email-masked]>
    Author/Change controller:
        Ian Hickson <[email-masked]>
    References:
         The http URL scheme is defined in: http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations, Opera Software

---

From: Ian Hickson <[email-masked]>
Date: Mon, 5 Mar 2012 17:55:02 +0000 (UTC)

On Mon, 5 Mar 2012, Yngve Nysaeter Pettersen wrote:
> > 
> > http://whatwg.org/html#http-aes-scheme
> 

The use case is being able to get private data from a provider A to a 
client C via an untrusted intermediary B, where the lack of trust is 
specifically over whether or not the intermediary will look at the data 
(as opposed to whether they will attempt to manipulate the data, which 
would be readily detectable and thus put an end to the A-B relationship 
typically via a lawsuit). The use case is addressed by encrypting the 
content before sending it to B (typically a CDN) and delivering the key 
with any URL referring to that content directly from A to C.

For example, the content could be a movie. "A" would be a movie 
distributor, "C" would be a consumer, and "B" would be a CDN. B is paid by 
A to host the content, but B might have rogue elements who would take all 
of the movie content and upload it to a copyright-violating community.

Another example would be YouTube with private videos. YouTube would like 
to cache private videos at the edge of the network on CDNs, but might want 
to use CDNs whose integrity is not entirely trusted.

Similar situations exist with other content types.

In both cases, this solution addresses the problem by encrypting the 
content at B (the CDN) such that the CDN cannot make use of the files, and 
serves the key directly from A's servers.

(We don't generally include rationale in the HTML spec, for practical 
reasons, though if anyone is interested in working with us to document 
them I'd be happy for the help; contact me off-list.)

> * Why is it better than using HTTPS?

The attack scenario is that the CDN itself isn't trusted not to look at 
the data. HTTPS only helps with on-the-wire attack scenarios.

> If the URL is sent over HTTPS you will very likely already have at least 
> one persistent HTTP connection open to the server (assuming it is the 
> same server) so establishing a new connection (same or different server) 
> for this request is not going to increase performance.

Relative to the current setup, there are no additional connections; the 
only difference is that the content at B (the CDN) is encrypted.

> * What is the keymaterial? If the userinfo is the key, how is it 
> encoded? Base64, hex, calculated (how?), or other format

The key is the userinfo value. (It's escaped in the URL, using the normal 
URL escaping rules.) I believe this is clear in the spec; let me know if 
the current text is ambiguous on this.

> where is the CTR nonce encoded?

The key is fresh per resource, so there's no need for a nonce, so it's 
zero. I've clarified this in the spec.

> securely to a new client, either for parallel use in multiple clients, 
> or system recovery?

There is typically going to be one key per encrypted resource. It is 
transmitted to the client with the URL; in normal operation, this would be 
done over HTTPS, from A to C directly. I'm not aware of a use case where 
it would need to be stored for long-term usage.

> plain HTTP, what should the client do if the URL is provided over HTTP 
> (or included by reference in a document loaded over HTTP)? Refuse to 
> perform the request, or go ahead anyway?

Anything transmitted over HTTP over an untrusted network is unsafe. 
There's not really anything more serious here than generally. It would be 
impossible to generically determine if the URL was obtained over encrypted 
channels or not (e.g. consider a URL constructed from parts obtained 
using XMLHttpRequest over both encrypted and unencrypted channels), so I 
don't think there's much point trying to block this.

> the Javascript Crypto APIs?

It does not, as far as I can tell. I'd be happy for this feature to be 
moved to a more appropriate spec if there is one, though.

> scheme?

They won't be able to access the content.

> It is quite possible that they will display the userinfo in the 

Displaying the userinfo to the user isn't particularly bad (it's random 
data, and the user is implicitly trusted with it anyway). Other attack 
scenarios in this situation seem like they'd apply to any bogus URL, and 
would need addressing independent of this scheme.

I believe this answers all the technical questions on this thread so far, 
let me know if I missed any.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 05 Mar 2012 18:09:35 +0000

In message <[email-masked]>, Ian Hick

>of the movie content and upload it to a copyright-violating community.

I'm sorry, but IMO this is just security-theater, and it represents
so terrible handling of key-material that it is deeply irresponsible
to even mention it in a standards document, without a lengthy list
of caveats and disclaimers.

Somebody should point Bruce Schneier at this, he needs a good laugh...

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 5 Mar 2012 21:08:50 +0100

> Somebody should point Bruce Schneier at this, he needs a good laugh...

I wouldn't go to such extremities, but at least I think that we're just
facing a layering violation. Only the contents have to be encrypted so
that the caches cannot use them, while the transport remains unchanged.
So a new scheme is not appropriate for this, a Content-Encoding would
be much better. User agents would be configured to know that content-
encoding XYZ requires a deciphering key whose ID is presented in the
header itself and should have been retrieved via another channel.

Example :
    Content-Encoding: aes-ctr-128; keyid=0x34751806
    Cache-control: no-transform

This has the benefit of working out-of-the-box without affecting existing
intermediary components.

Regards,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 05 Mar 2012 21:41:59 +0000

>This has the benefit of working out-of-the-box without affecting existing

That doesn't really improve the crypto scheme or key-handling in
any meaningful way.

It does make it slightly less hackish as HTTP considered.

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 5 Mar 2012 22:58:39 +0100

> It does make it slightly less hackish as HTTP considered.

Something along the lines of

Link: <https://serverA/keys/1234>; rel="content-decryption"

would expose the key only to parties authorized to retrieve it. If the
client sends the resource URL in the referer header, then the key url
does not need to be specific even, but the matching key could be 
selected by serverA. 

<green/>bytes GmbH

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 5 Mar 2012 23:24:26 +0100

> It does make it slightly less hackish as HTTP considered.

That was precisely my point : make it do *the same* without redefining
a new scheme. I'm not judging whether or not doing this is useful, I'm
saying it can already be done if needed.

Regards,
Willy

---

From: Ian Hickson <[email-masked]>
Date: Mon, 5 Mar 2012 15:20:24 -0800

> of caveats and disclaimers.

Could you elaborate on this? In particular, what risks do you believe exist
here given the scenario this is intended to address and given the list of
issues to consider already given in the specification?

I'm eager to address any problems that exist with this proposal, but I am
failing to reconcile the proposal as I understand it with your assessment
of it above.

-- 
Ian Hickson

---

From: Ian Hickson <[email-masked]>
Date: Mon, 5 Mar 2012 23:29:16 +0000 (UTC)

On Mon, 5 Mar 2012, Willy Tarreau wrote:
> So a new scheme is not appropriate for this, a Content-Encoding would be 
> much better. User agents would be configured to know that content- 

This would require changes at the intermediaries. It would also require a 
mechanism to link keys to IDs, which is non-trivial given the same-origin 
policy, multiple browsing contexts, subresources, etc.

> This has the benefit of working out-of-the-box without affecting 
> existing intermediary components.

It would seem to me to require slightly more effort than the scheme 
approach on this front.

(We did actually consider something like this.)

---

From: David Morris <[email-masked]>
Date: Mon, 5 Mar 2012 15:41:32 -0800 (PST)

>From what you've said, this appears to be a shared key system which
provides marginal protection against abuse of the cache but with
wide distribution of the key, it does seem to me to be providing
a significant challange to abuse of the key.

As I understand the suggested use case, a cache will have encrypted
content placed there by the content owner (or agent) and then
multiple users will be provided the URL and key for retrieval.

Sounds pretty weak to me.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 06 Mar 2012 00:18:48 +0000

In message <[email-masked]>

>issues to consider already given in the specification?

The major risk is that people understand neither how little privacy
this buys them, nor how trivially easy it is to compromise that
privacy accidentally.

The proffered strawman about copyright protection is not credible:

You cut and paste the link, and anybody who receives it can view
the copyrighted object, and you have no idea who leaked it.

That's pretty much exactly what the Copyright-Monopolies try to
avoid, they want per-licensed-copy unique links, so the can see
who copy&pasted it.

There is no way to salvage this, if you do not strengthen the
key-handling.

If instead of the actual key, you provided the identifier for a
pre-shared key, to be read from local storage on the client machine,
then the link would not work for anybody who didn't have the
pre-shared key in their "secrets" file.  (If you label the keys
individually per licensee, and you can see who tried to leak the
non-working links of you want to.)

That of course means that you need to provide a way to pre-share
the keys, and yes, that means that it will not work "by magic"
without user-involvment, but that is exactly what is necessary to
make this more robust:  You want people to realize that this is
secret key-material, you don't want to, as proposed, not even make
the user aware that it is there in the first place.

Trying to get benefits from crypto while trying to hide the fact
that it is not there, does not work, if people don't know it is
there, they don't know that they have to be careful not to break it.

Another problem is that this scheme does not offer any integrity.

Your malicius CDN could truncate your object and you would never
notice that the last 2 pages of the contract are missing.

Having been through the mill a couple of times myself, I can not
recommend strongly enough, that you try to get at least one
card-carrying cryptographer to go over the key-handling and the
cryptographic operations, before you try to standardize anything
involving a cryptographic algorithm.

Do it right, there are no workable shortcuts in crypto.

---

From: Ian Hickson <[email-masked]>
Date: Tue, 6 Mar 2012 01:14:04 +0000 (UTC)

On Mon, 5 Mar 2012, David Morris wrote:
> provides marginal protection against abuse of the cache but with wide 
> distribution of the key, it does seem to me to be providing a 
> significant challange to abuse of the key.
> 
> content placed there by the content owner (or agent) and then multiple 
> users will be provided the URL and key for retrieval.
> 

What would you suggest instead?

Note that there is no more risk to giving the users the key than there is 
from giving them the content itself, as far as I can tell.

A typical use case would be some parents taking a video of their daughter, 
and uploading it to YouTube marked as a private video (knowledge of the 
URL is what is required to access it). The grandparents would then be 
given the URL to the video, so they can see it. Today, there's no way to 
put the video on an untrusted CDN, which means that to protect the video 
from unauthorised access, one has to compromise performance (the data will 
be further from the grandparents than it could if on the untrusted CDN).

In this scenario, the grandparents are trusted with the content and with 
the URL to the content. Why would they not be trusted with the key?

---

From: Ian Hickson <[email-masked]>
Date: Tue, 6 Mar 2012 01:26:26 +0000 (UTC)

On Tue, 6 Mar 2012, Poul-Henning Kamp wrote:
> 
> The major risk is that people understand neither how little privacy this 
> buys them, nor how trivially easy it is to compromise that privacy 
> accidentally.

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

> You cut and paste the link, and anybody who receives it can view the 
> copyrighted object, and you have no idea who leaked 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.

> Trying to get benefits from crypto while trying to hide the fact that it 
> is not there, does not work, if people don't know it is there, they 
> don't know that they have to be careful not to break it.

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.

> Your malicius CDN could truncate your object and you would never notice 
> that the last 2 pages of the contract are missing.

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 couldn't be used with other generic 
integrity checking mechanisms, though.

> involving a cryptographic algorithm.

This isn't my first barbecue either.

---

From: "Eric J. Bowman" <[email-masked]>
Date: Mon, 5 Mar 2012 20:07:18 -0700

> (We did actually consider something like this.)

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, [email-masked] -- 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

---

From: Ian Hickson <[email-masked]>
Date: Tue, 6 Mar 2012 04:06:29 +0000 (UTC)

On Mon, 5 Mar 2012, Eric J. Bowman wrote:
> Who is "we" and where are these conversations archived?

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

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 6 Mar 2012 15:07:31 +1100

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 content after following the redirect supposed to be encrypted or not? Does it matter if the redirect goes to a different origin?
HTTP errors (with a response body) will, presumably, not be encrypted. I hope a 500 error with a response body containing javascript cannot get the http+aes URL from, say, window.location.

4. I am not sure what an http+aes URL means to the user-agent. Obviously if the user-agent gets an encrypted body it can decrypt it with the given key. Should it reject a response with a cleartext body? Probably not as http+aes was not offering any integrity or authentication anyway.

Does an http+aes URL have the same "origin" as an http URL (for same-origin purposes, the Origin HTTP header etc)?

--
James Manger

---

From: "Eric J. Bowman" <[email-masked]>
Date: Mon, 5 Mar 2012 21:21:20 -0700

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

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

---

From: Adrien de Croy <[email-masked]>
Date: Tue, 06 Mar 2012 17:59:04 +1300

Seems to me there's a bunch of confusion about the purpose and goals of 
this scheme.

 From what I can see, its sole purpose is to enable the communication of 
a key to a client so that it can decrypt content.  the URI-scheme 
basically is used to multiplex the key into the URI, and identify itself 
as such so that the userinfo part can be correctly interpreted.  After 
that it's just HTTP.

There's another way to achieve a similar thing, such as Progressive 
Networks did with RAM files.

Have the URI point to a small file which contains the information 
required - target URI of encrypted content, and key, encoding, and 
checksum for integrity.

The client clicks the link, this file comes down with a specific content 
type, which triggers processing.

No changes to intermediaries, no new scheme.  Just a new content type.

Downside is 1 more round trip to fetch the info, but I think the 
benefits would outweigh that, since you can then transport a lot more 
information than you'd otherwise have to squeeze into a userinfo part of 
a URI.  You get independent control of this information as well, and it 
can have a different life-cycle than just a URI would.

A lot less risk of leakage also, since the info could be fetched by 
https, and secured to the requestor (i.e. whoever is allowed to view the 
content).

In any case, relying on client behaviour for security is never going to 
give security, but it sounds like this isn't really the primary goal of 
this system.

Adrien

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/

---

From: Ian Hickson <[email-masked]>
Date: Tue, 6 Mar 2012 05:04:48 +0000 (UTC)

On Mon, 5 Mar 2012, Eric J. Bowman wrote:
> 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.

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

---

From: "Eric J. Bowman" <[email-masked]>
Date: Mon, 5 Mar 2012 22:51:10 -0700

Ian Hickson wrote:
> Eric J. Bowman wrote:
> > 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.
> 

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 6 Mar 2012 07:23:02 +0100

On Mar 6, 2012, at 05:07, Manger, James H wrote:

> 1. Encryption without integrity (as http+aes delivers) is almost worthless.

That is certainly true if we were talking about actual security objectives.
However, it seemed to me this is about DRM, not about security, so maybe it is more important to be able to claim "the content [sic] is encrypted with 256-bit AES" than to get actual security against sophisticated attacks (which would trivially target Ian's party "A" instead of this scheme here).

With the security issues properly spoken for, something different.

The more interesting observation for me is that there is an HTTP URI stuck in there trying to get out.

I.e., instead of 

http+aes://[email-masked]/tehmovie.mov

one would really like to see

frob:hixie-3:uEdF00VkBLCfriveitl6cv4H:http://cdn.com/tehmovie.mov

From the point of the server B (and most parts of the mechanics in client A), this is a normal HTTP request, so we have that normal HTTP URI as the third element of the frobnicating URI scheme (and it could be ftp:// for that matter).  All we want is that, once HTTP has done its magic, the retrieved content [sic] is post-frobnicated in some way, e.g. in process hixie-3 that uses keying material uEdF00VkBLCfriveitl6cv4H and AES-CTR to decrypt the payload in some as yet unspecified way.  The explicit indication of the post-processing style provides algorithm agility and decouples the URI scheme from the specific type of post-frobnicating.  A simple registry could be used to manage the post-frobnicating specifications (which, apparently, still need to be written -- outside the HTML spec, please).

Why does post-frobnicating have to be part of the URI at all (as opposed to a header field like Content-(En)coding etc.)?  Of course, that is not *necessary*, but I do see the convenience factor of lumping this in there.  (It also can be used for pre-frobnicating for request bodies.)

Grüße, Carsten

PS.: Consistent with the ~ 12 % facetious content of this message, Apple's spelling correction is trying to change "frobnicating" into something else...  I hope none of that is left in this message.  But I'm quite serious that, if this is done, it should be done this way.

---

From: Ian Hickson <[email-masked]>
Date: Tue, 6 Mar 2012 06:40:09 +0000 (UTC)

On Mon, 5 Mar 2012, Eric J. Bowman wrote:
> March?

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

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 6 Mar 2012 07:55:07 +0100

On Mon, Mar 05, 2012 at 11:29:16PM +0000, Ian Hickson wrote:
> This would require changes at the intermediaries.

If your goal is that intermediaries don't know the contents then no,
doing this is enough for existing intermediaries to cache the contents
without touching it and without understanding it.

> It would also require a 

So you mean that it's the *real* decryption key which is passed in userinfo ?
It appeared obvious to me that it was just an identifier for a key that the
client had fetched somewhere else (eg: on the same site via https or at least
without passing via the CDN). If the real key is passed in the response, then
I fail to get the use case since your CDN gets the key as well :-/

> It would seem to me to require slightly more effort than the scheme 

It depends on how far the http+aes scheme is visible. Will a browser send
"GET http+aes://xxxxx HTTP/1.1" to a browser or will it know that it must
use the "http" scheme when asked for "http+aes" ?  And what scheme will be
used for redirects ? Will cookies be passed to http+aes requests ? Will
javascript be able to perform http+aes requests, and if so, what are the
security implications (eg: will it make it possible for malware to build
huge collections of deciphering keys and make them public).

It doesn't look like it's that much obvious to me.

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Mar 2012 09:01:56 +0100

> This would require changes at the intermediaries. It would also require a

Sorry?

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 06 Mar 2012 09:25:42 +0100

On Tue, 06 Mar 2012 07:55:07 +0100, Willy Tarreau <[email-masked]> wrote:
> So you mean that it's the *real* decryption key which is passed in  
> userinfo? It appeared obvious to me that it was just an identifier for a  
> key that the client had fetched somewhere else (eg: on the same site via  
> https or at least without passing via the CDN). If the real key is  
> passed in the response, then I fail to get the use case since your CDN  
> gets the key as well :-/

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.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 06 Mar 2012 09:03:44 +0000

In message <[email-masked]>, Ian Hick

>given the URL to the video, so they can see it.

First of:  This is so ridiculous that you almost made me do a spittake.

You expect baby-parents to know about AES keys in hex ?

Gimme a break...

Second, Youtube don't accept contents that doesn't conform to one
of their approved video formats and if the video has too much entropy
(attempted steganography) they will also reject it.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 06 Mar 2012 09:08:23 +0000

In message <[email-masked]>, Ian Hick
>really matter if they don't understand it.

Yes, it does matter, it matters a lot, because secrets are only
secret if people know they need to keep them secret.

That said, the people I was talking about here, were the people who
would decide to use this scheme because they are unlikely
to understand the implications and limitations of this bad idea.

>integrity checking mechanisms, though.

There is no reason to standardize something which does not do what
people would expect it to.

This proposal should be withdrawn with prejudice, it is simply not
done to hand people a cryptographic handgrenade of this kind.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 6 Mar 2012 11:57:44 +0100

Hi Anne,

> C never knows anything about the bits it is hosting, S and the user agent  

This is what I understood first but Ian's explanation seems to imply that
the key itself is passed along with the response because it would otherwise
be too complex to manage keys. Maybe there is something that I did not
understand then.

Willy

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 6 Mar 2012 13:33:20 +0100

On Mar 6, 2012, at 11:57, Willy Tarreau wrote:

> Maybe there is something that I did not
> understand then.

Maybe I'm beating a dead horse, but the use case is pretty obvious.

A is a user with their browser.
C is a "content" "owner".
B is a CDN.

A has C's website open and wants to view a movie.
C wants you use B for the delivery of that movie, but doesn't trust B very much.
C does trust A a lot, though (I don't know why, but see below).
So C gives A a reference to content in B that only A will know how to decrypt.
For implementation convenience, we encode both the reference and the keying material in one thing, a URI.
(See my previous message on how to do this in a cleaner way.)

Why does this make any sense whatsoever?
You have to make a quantitative argument; on the qualitative level it doesn't.
The reason is that a CDN that has a copy of all of C's movies is a big treasure chest, and "C trusts B" in reality means "B is prepared to incur a lot of liability towards C if things go wrong".
C may not trust A that much either, but at least A only gets one movie and not the whole treasure chest.

This is not a very bright security scheme (A can hand out the URI+key to all their friends and megaupload as well).  But maybe it is good enough for "DRM".  It's certainly better than leaving the treasure chest on B, if C wants to encourage competition between Bs and lower their price for engaging Bs.  (C can limit the damage by rotating the copies on all of its Bs relatively quickly, which may still be less bandwidth than from A to all Cs.  There are some pretty obvious ways to do fingerprinting here, as well.  And then there is DECADE...)

The specification for this would have to make clear the limited applicability of this scheme.  This may be one reason not to have it in the HTML spec, because that is very big already and is not a good place for rationale, applicability etc.  Whether saying "this is not a new solution to the HTTPS problem" is going to help at all -- we can argue that a long time.

Grüße, Carsten

---

From: Jim Ancona <[email-masked]>
Date: Tue, 6 Mar 2012 14:37:47 -0500

Could this use case be accomplished with a new Media-Type plus a
fragment identifier definition, rather than a new URI scheme? If so,
might that be a better approach?

Jim

---

From: Ian Hickson <[email-masked]>
Date: Wed, 7 Mar 2012 00:23:45 +0000 (UTC)

On Tue, 6 Mar 2012, Manger, James H wrote:
> 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 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.)

> 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).

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) where the 
integrity concern is real and the privacy concern is not. For example, one 
can imagine a situation in which a Linux distribution is available on 
dozens of mirror sites, and one site is hostile and embeds malware into 
their copy of the distribution. This is an entirely separate and 
orthogonal issue, and not one that this proposal in any way attempts to 
address. If it should be addressed, then it should be addressed 
separately. (Proposals to address this do come up occasionally; so far 
none have caught the imagination of Web browser vendors.)

> 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.

If we need a different algorithm, we can just create a new set of 
scheme(s). That seems trivial.

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

This is defined in the relevant specifications: you follow the redirect 
and its semantics.

> Is the content after following the redirect supposed to be encrypted or 
> not?

It is not, just like if an HTTP site redirects to an FTP URL, you don't 
use the HTTP protocol with the FTP site.

> Does it matter if the redirect goes to a different origin?

That seems like an orthogonal issue.

> HTTP errors (with a response body) will, presumably, not be encrypted.

As specced, they would be decrypted (into garbage).

> I hope a 500 error with a response body containing javascript cannot get 
> the http+aes URL from, say, window.location.

A 500 error containing JS would be garbled and so couldn't access the URL.

> 4. I am not sure what an http+aes URL means to the user-agent. Obviously 
> if the user-agent gets an encrypted body it can decrypt it with the 
> given key. Should it reject a response with a cleartext body? Probably 
> not as http+aes was not offering any integrity or authentication anyway.

There is no way to determine if the body is cleartext or not. By 
definition, it is encrypted.

> Does an http+aes URL have the same "origin" as an http URL (for 
> same-origin purposes, the Origin HTTP header etc)?

Its origin is determined as for any other URL, resulting in a (scheme, 
host, port) tuple.

> frob:hixie-3:uEdF00VkBLCfriveitl6cv4H:http://cdn.com/tehmovie.mov

That's not a bad idea, but it seems unfortunate to introduce yet more 
variation in URL scheme syntaxes, which is why I didn't go in that 
direction with the proposal and instead used Kornel's http+aes:// idea.

> required - target URI of encrypted content, and key, encoding, and 

This would require significantly more complexity to implement, not to 
mention the extra round-trip to use (unless we used data: URLs, at which 
point we're really just back to a complicated-looking URL scheme).

The advantage of http+aes:// is that it fits anywhere you can put a URL 
scheme, with no change to the underlying infrastructure.

> You expect baby-parents to know about AES keys in hex ?

It's the hosting site that would be doing the encryption, not the parents. 
The parents already trust the hosting site, but the hosting site might not 
trust all the CDNs they might want to use.

On Tue, 6 Mar 2012, Willy Tarreau wrote:
> > >userinfo? It appeared obvious to me that it was just an identifier 
> > >for a key that the client had fetched somewhere else (eg: on the same 
> > >site via https or at least without passing via the CDN). If the real 
> > >key is passed in the response, then I fail to get the use case since 
> > >your CDN gets the key as well :-/
> > 
> > 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.
> 
> This is what I understood first but Ian's explanation seems to imply 
> that the key itself is passed along with the response because it would 
> otherwise be too complex to manage keys. Maybe there is something that I 
> did not understand then.

Anne's description is correct. I apologise for not conveying it as 
precisely as he did.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 6 Mar 2012 17:06:03 -0800

> A 500 error containing JS would be garbled and so couldn't access the URL.

Ian,

If I understand your reasoning here, it's that the body of the error would be
encrypted by an unknown key and therefore the attacker cannot put chosen
JS here?

If so, that's not obviously correct. Consider the case where the header of
the content is known (e.g., because it contains meta-information about
the content). In that case, an attacker can use the properties of CTR to
produce a ciphertext that maps to a predictable plaintext, thus
mounting the attack described here.

Best,
-Ekr

---

From: Henrik Nordström <[email-masked]>
Date: Wed, 07 Mar 2012 02:49:15 +0100

> This would require changes at the intermediaries.

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.

> policy, multiple browsing contexts, subresources, etc.

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

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 7 Mar 2012 12:48:46 +1100

Ian,

> provided by this proposal.

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).]

> This seems like a very reasonable assumption.

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 integrity)... to tackle one way to violate privacy while other (somewhat more complex) ways remains for the same attacker. This is not a good candidate for a standard, certainly not for HTML5.

> use the HTTP protocol with the FTP site.

Ugh? So if the CDN web site introduces a redirect before returning the encrypted content it will break (the user-agent now expects plaintext)!

> As specced, they would be decrypted (into garbage).

Argh. Gratuitously breaking HTTP.

> definition, it is encrypted.

Not setting a content-type (or content-encoding) to indicate the encryption is more gratuitous breaking of HTTP (for no reason - presumably CDNs can be configured with content-type header values).

--
James Manger

---

From: "Michael Wojcik" <[email-masked]>
Date: Wed, 7 Mar 2012 09:13:08 -0600

> From: Poul-Henning Kamp [mailto:[email-masked]]
> Sent: Monday, 05 March, 2012 19:19
> To: Ian Hickson
> 

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 storage is cheap.

Would such an argument stand up in court? I don't know, but I wouldn't
want to be the one fighting it. And, of course, it puts users in the
position of having to prove their keys weren't stolen.

It also opens the door to region-locking schemes and similar annoyances.

-- 
Michael Wojcik
Technology Specialist, Micro Focus

This message has been scanned by MailController - portal1.mailcontroller.co.uk

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 07 Mar 2012 16:32:49 +0000

In message <[email-masked]

>- Publisher puts 100 copies of each resource on CDN, each encrypted with

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

---

From: "Michael Wojcik" <[email-masked]>
Date: Wed, 7 Mar 2012 11:15:41 -0600

> Sent: Wednesday, 07 March, 2012 11:33
> 

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.

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

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

---

From: Anthony Bryan <[email-masked]>
Date: Wed, 7 Mar 2012 20:53:52 -0500

> none have caught the imagination of Web browser vendors.)

this is addressed by Metalink in RFC 5854 (XML) & RFC 6249 (HTTP,
using the Link & Digest header fields).

multiple mirrors, full & partial file checksums, and other information
to aid in download completion can be included. (there is also work on
an FTP HASH command for requesting hashes of files,
draft-ietf-ftpext2-hash)

many Linux distributions, LibreOffice, OpenOffice.org, etc, use
Metalink and quite a few download applications support it for 7 years.

but you're right, most browser vendors haven't caught on. correctly
downloading large files would be very helpful to a number of
communities. we'd like to work with them to address any concerns if
they are interested!

>> required - target URI of encrypted content, and key, encoding, and

I'm not suggesting Metalink for this since it appears to have been
ruled out, but either the XML or HTTP version could be extending to do
just this.

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 8 Mar 2012 07:58:05 +0100

> direction with the proposal and instead used Kornel's http+aes:// idea.

"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 spec.

Grüße, Carsten