Encryption content coding simplification

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Encryption content coding simplification

Martin Thomson-3
Based on the review from ekr and the discussion at the last meeting,
I've put together a pull request on the encrypted content coding spec
that proposes to remove a bunch of the complexity from the spec. I
think that it's a lot simpler:

https://github.com/httpwg/http-extensions/pull/218

I have a uploaded preview of the resulting spec here:
http://httpwg.org/http-extensions/simple_base/draft-ietf-httpbis-encryption-encoding.html

I have a corresponding change on the webpush spec to take the parts of
what was removed that they rely on.

This is a fairly big change.  I think that it's prudent to run WGLC
again after this change.

Reply | Threaded
Open this post in threaded view
|

Re: Encryption content coding simplification

Poul-Henning Kamp
--------
In message <[hidden email]>, Martin Thomson writes:
>Based on the review from ekr and the discussion at the last meeting,
>I've put together a pull request on the encrypted content coding spec
>that proposes to remove a bunch of the complexity from the spec. I
>think that it's a lot simpler:
>
>https://github.com/httpwg/http-extensions/pull/218

It certainly is.

But relative to the discussion about how many specialized parsers
we have forced people to write, this draft seems to add yet another
for the new headers.

I think we should try to, and easily can avoid that.

        Content-Encoding: aesgcm, aesgcm
        Encryption: keyid="mailto:[hidden email]";
                    salt="NfzOeuV5USPRA-n_9s1Lag",
                    keyid="bob/keys/123";
                    salt="bDMSGoc2uobK_IhavSHsHA"; rs=1200

Keyid, salt and rs are parameters to the Content-Encoding,
so in a perfect world, we would send this as:

        Content-Encoding:
                aesgcm;keyid="mailto:[hidden email]";
                    salt="NfzOeuV5USPRA-n_9s1Lag",
                aesgcm;keyid="bob/keys/123";
                    salt="bDMSGoc2uobK_IhavSHsHA";
                    rs=1200

That is a non-trivial extension of RFC7231's "content-coding", which
may or may not cause existing implementations to needlessly reject
these transactions.

I suggest we run a few tests to see what happens in the real world.

If extending C-E is impractical, we should put the Encryption header
on "common structure" form, by having it reference its corresponding
token from the C-E header explicitly:

        Content-Encoding: aesgcm, aesgcm
        Encryption: aesgcm;keyid="mailto:[hidden email]";
                    salt="NfzOeuV5USPRA-n_9s1Lag",
                    aesgcm;keyid="bob/keys/123";
                    salt="bDMSGoc2uobK_IhavSHsHA"; rs=1200

That has the added advantage of being a clean extension point
past aesgcm down the road:

        Content-Encoding: aesgcm, caesar
        Encryption: aesgcm;keyid="mailto:[hidden email]";
                    salt="NfzOeuV5USPRA-n_9s1Lag",
                    caesar;shift=52

But if we've come all this way, we might as well generalize
"Encryption" to a "CE-params", that can carry parameters for any
C-E:

        Content-Encoding: aesgcm, caesar, supercompress
        CE-params: aesgcm;keyid="mailto:[hidden email]";
                    salt="NfzOeuV5USPRA-n_9s1Lag",
                    caesar;shift=5,
                    supercompress;dictionary=11

With this approach the new Crypto-Key header surplus to
requirements: The key is simply another parameter, and
we avoid having to match the key-id from two different
headers with each other, and all the corner-cases that
brings:

        Content-Encoding: aesgcm, caesar, supercompress
        CE-params: aesgcm;key="csPJEXBYA5U-Tal9EdJi-w";
                    salt="NfzOeuV5USPRA-n_9s1Lag",
                    caesar;shift=5,
                    supercompress;dictionary=11

And finally, we want a "binary blob" type in the common structure,
the two we have here would be marked as such, for instance with
the "\#" I proposed in my strawman:

        Content-Encoding: aesgcm, caesar, supercompress
        CE-params: aesgcm;key="\#csPJEXBYA5U-Tal9EdJi-w";
                    salt="\#NfzOeuV5USPRA-n_9s1Lag",
                    caesar;shift=5,
                    supercompress;dictionary=11

Please ?

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