Re: Working Group Last Call: Encrypted Content-Encoding for HTTP

Thanks again, I've added your suggested changes to the PR.

Trimming aggressively here.

On 23 June 2016 at 01:06, Magnus Westerlund
<magnus.westerlund@ericsson.com> wrote:
> However, I think the other part of this comment is the question can one put
> a limitation on how big value rs can be at all. Like max 2^64? Simply as
> guidance to implementors? I know this hasn't been the usual style in HTTP
> related specs to put upper limit to values.

I see no reason to set a lower limit than RFC 5116 has here.  Most
modern machines are happy with 64-bit numbers, and those that are less
happy probably don't want to deal with that much data anyway.  I've
set rs to the maximum plaintext defined in RFC5116.

> So this comes down to the question if one likes to define one new Crypto-Key
> parameter for each new cipher version of the encrypted content encoding, or
> if one likes to have a generic explicitly included IKM material string,
> where one uses only the Key-ID to bind to the specific encoding.

6 of one, half-dozen of the other :)  I've adopted your proposed edit.

> And this is a name = value pair. Thus, to correct the limiation if that is
> intended to say that it is not okay to include multiple identical name value
> pairs then it should be changed to:
>
>     Encryption header field values with multiple instances of the same
>     parameter name and value is invalid.

I think that implies a narrower restriction, that is that a=b;a=b is
bad, but a=b;a=c maybe isn't.  How about I instead modify the
paragraph before to make it clear that multiple encryptions ==>
multiple header field values.  That should help clarify what the
document means by header field values.

>    The "aesgcm" content-coding uses a fixed record size.  The resulting
>    encoding is either a single record or series of fixed-size records,
>    with a final record that is one or more octets shorter than a fixed
>    sized record. Note that for single record use the value of fixed
>    sized record parameter "rs" MUST be larger than the single record
>    created.

I've paraphrased, but this is a fine change.

> I think I need to think more on the removal and discuss with my colleagues
> more. I become uncertain what the implications become in the case one
> applies resource maps for the Out of band encoding as discussed in B.2 of
> https://tools.ietf.org/html/draft-reschke-http-oob-encoding-06#appendix-B.2

I've convinced myself that this is OK by considering resource maps as
a form of aggressive compression for HTTP/2 server push.  I know that
Göran and others have a different conception of this, so if you find
that this doesn't work, we should discuss it.

Given that the removed paragraph doesn't actually stipulate any
requirements, I think that we could change our view about where things
live and simply write down those conclusions in a newer document.

Received on Thursday, 23 June 2016 06:43:35 UTC