- From: Magnus Westerlund <magnus.westerlund@ericsson.com>
- Date: Tue, 21 Jun 2016 16:41:38 +0200
- To: HTTP Working Group <ietf-http-wg@w3.org>, Martin Thomson <martin.thomson@gmail.com>
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