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

Hi,

Some few comments, but I think these issues have resolution from my 
perspective.

Den 2016-06-23 kl. 08:43, skrev Martin Thomson:
> 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.

Fully agree that there are no point of using a lower number than what 
RFC5116 says for AESGCM. However, the Encryption header is clearly not 
AESGCM specific, thus in future definitions we might se RS values that 
can be larger. That was my initial point here.

I guess implementors HTTP parameter parsers are going to be robust to 
unknown field lengths. Thus, specifying the maximum RS on a per encoding 
(cipher) level is probably fine.


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

Yes, that is probably less confusing.


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

Yes, I believe this is fine.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

Received on Thursday, 23 June 2016 11:16:50 UTC