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

Hi,

I have reviewed the draft. Sorry for being a bit late, but I hope my 
comments can be of use.

1. Section 2:
    The record size defaults to 4096 octets, but
    can be changed using the "rs" parameter on the Encryption header
    field.

I think this default value is quite small. If one want to do random 
access the record boundaries becomes a question of the need for random 
access into the resource and the need for streaming data that can be 
released from the decryption and integrity verification at record 
boundaries. I think the text could be more clear on the motivation and 
trade-offs here.

I also think there need to be discussion of the case where a single 
record with actual data is all that is needed.

2. Section 2:


           +------+         input of between rs-65537
           | data |            and rs-2 octets
           +------+      (one fewer for the last record)
               |

First I interpreted this figure part as a limitation in RS sizes. I 
didn't graso that it was RS minus number of padding bytes (2-65537) of 
data in this particular record that was the intention. I think it could 
benefit from a clarification of that it is "rs minus padding size 
(2-65537) number of bytes".

3. Section 2:

    A sequence of full-sized records can be truncated to produce a
    shorter sequence of records with valid authentication tags.  To
    prevent an attacker from truncating a stream, an encoder MUST append
    a record that contains only padding and is smaller than the full
    record size if the final record ends on a record boundary.  A
    receiver MUST treat the stream as failed due to truncation if the
    final record is the full record size.

This is clear on truncation at the end of the resource. However, it 
fails to describe how one detect and handle reordering or truncation 
from front. To my understanding it is the nonce derivation and the need 
for correctly knowing the sequence number of a record that prevents that 
attack. So that failure in decrypting and verifying a record may depend 
on reordering or truncation from front. Then that it may also depend on 
data corruption or other reasons is another matter.


4. Section 3.1:

    rs:  The "rs" parameter contains a positive decimal integer that
       describes the record size in octets.  This value MUST be greater
       than 1.  If the "rs" parameter is absent, the record size defaults
       to 4096 octets.

This specifies no upper limit for the value of RS. Can I use a value 
larger than a 32-bit integer? I see there is a point of providing the 
implementors a guidance on what values may occur here. It is also 
clearly dependent on the algorithms security properties, which may 
introduce limitations. To my knowledge the limit for AES-GCM is 2^39-256 
bytes to maintain the security properties.

5. Section 3.2:

Several of the abbreviations such as PRK and CEK are not explained.


6. Section 3.2:

   CEK = HMAC-SHA-256(PRK, cek_info || 0x01)

What is the 0x01 concatenated to the cek_info before the hashing? I 
would guess some sequence number for avoiding key reuse, but it is not 
clear that it is needed due to different inputs in the first and second 
step.

7. Section 4 and 4.1:

    aesgcm:  The "aesgcm" parameter contains the base64url-encoded octets
       [RFC7515] of the input keying material.

I don't understand why this parameter is called "aesgcm". To me the only 
requirements on the IKM is that is is at least 16 bytes and have been 
bas64URL encoded when put into the header. So what is the relation to 
AESGCM?

8. Section 5.3:

Section 3 says:

    Encryption header field values with multiple instances of the same
    parameter name are invalid.

The example in 5.3 is:

    PUT /thing HTTP/1.1
    Host: storage.example.com
    Content-Type: application/http
    Content-Encoding: aesgcm, aesgcm
    Content-Length: 1235
    Encryption: keyid="mailto:me@example.com";
                salt="NfzOeuV5USPRA-n_9s1Lag",
                keyid="http://example.org/bob/keys/123";
                salt="bDMSGoc2uobK_IhavSHsHA"; rs=1200

Isn't this example violating the rules in Section 3 for the Encryption 
header?

9. Section 5.4 and 2:

I find nothing in Section 2 that indicates that there are requirement of 
supporting a mode of a single record of encryption. My reading indicates 
that the minimal usage is possibly first a single record followed by a 
padded stop record. It is also not clear that the "rs" parameter is 
optional.

Please clarify.

10. Section 3:

    The Encryption header MAY be omitted if the sender does not intend
    for the immediate recipient to be able to decrypt the payload body.
    Alternatively, the Encryption header field MAY be omitted if the
    sender intends for the recipient to acquire the header field by other
    means.

I wonder about this. If the Encryption header is omitted how is the 
receiving agent knowing how to later match the resource with the correct 
key-management data. URI and etag? I mean if one include the key-id for 
the received resource then one know that one has the right key in 
relation to the resource version one have stored. It might even be the 
case that a later version of the resource is protected using the same 
key but with a different salt.


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 Tuesday, 21 June 2016 14:42:14 UTC