W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: I-D Action: draft-ietf-httpbis-encryption-encoding-04.txt

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 1 Nov 2016 15:39:00 +0100
To: ietf-http-wg@w3.org
Message-ID: <9de93353-e86d-9d57-6ea9-a802d18c7305@gmx.de>
On 2016-11-01 00:29, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Hypertext Transfer Protocol of the IETF.
>
>         Title           : Encrypted Content-Encoding for HTTP
>         Author          : Martin Thomson
> 	Filename        : draft-ietf-httpbis-encryption-encoding-04.txt
> 	Pages           : 16
> 	Date            : 2016-10-31
>
> Abstract:
>    This memo introduces a content coding for HTTP that allows message
>    payloads to be encrypted.
> ...

I have updated my Java P.o.C. at 
<https://gist.github.com/reschke/46659c912b426dffeac41d9a21421c95> 
accordingly.

However, there's some weirdness in 
<https://greenbytes.de/tech/webdav/draft-ietf-httpbis-encryption-encoding-04.html#rfc.section.4.1> 
- the record size now used appears to be 41626 (it doesn't matter a lot 
because it's a single truncated record, but still).

I assume that wasn't intentional, as the version in git has an updated 
example, but that gives me even a weirder rs.

In general I'd like the examples to be a bit more verbose - spell out 
the record size and salt (previously the salt was in a header field), 
and maybe mention what padding was used (the second example uses two 
records, where one has 0 padding bytes, and the other has 1 -- you 
really have to implement...).

Which leads me to another thought: it would be good to explain somewhat 
more when padding would be useful. In particular, if you write a library 
that implements an encoder, what would be a good way to specify padding? 
Having the same padding in every record probably wouldn't be good, right?

Best regards, Julian
Received on Tuesday, 1 November 2016 14:39:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 November 2016 14:39:39 UTC