Subject: Secdir last call review of draft-ietf-httpbis-encryption-encoding-08

From: Robert Sparks <[email-masked]>
Date: Wed, 05 Apr 2017 13:47:53 -0700

Reviewer: Robert Sparks
Review result: Ready

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Document : draft-ietf-httpbis-encryption-encoding-08

Summary: This document is ready for publication as Proposed Standard
(except perhaps for one recommendation)

This document defines a content encoding for encrypting the contents
of an HTTP message that
facilitates storing the encrypted contents and decrypting the content
for rendering incrementally
(before the full content is received). The draft is clear, and
implementation should be straightforward.
It's security considerations section is detailed.

I did not verify the math that went into the provided examples.

My only concern is that the document suggests it would be ok to use a
counter to provide a unique salt value
for each message. I suspect that provides the kind of information leak
the draft discusses avoiding.

I also pointed out a couple of nits to the editor, and those are
addressed already in his working copy (on github).

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Apr 2017 08:32:42 +1000

> the draft discusses avoiding.

Hi Robert, can you explain what sort of leakage you are concerned
about?  I mean, I can understand how you could construct the sequence
of resources that were encrypted using a counter for the salt, but I
don't know what that might imply.

That said, I think that the counter thing can be removed.  We require
128 bits of salt, which is a space that is large enough to select
randomly from in perpetuity.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 6 Apr 2017 09:47:08 -0500

> don't know what that might imply.
Things like these:

- A third party that could see that sequence would know if there were gaps.

- If creation or transmission time can be approximated (perhaps via file 
stats),
   the third party can more quickly assess the rate of creation, and 
have a strong
   idea of when to look for the next one.

Of course for both of those, the 3rd party would need to somehow know the
content came from the same source, but it's easy to see systems built 
using this
that would expose that.
> randomly from in perpetuity.
That would be my personal preference.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Apr 2017 09:43:13 +1000

> That would be my personal preference.

Sold.  https://github.com/httpwg/http-extensions/commit/8c31395609cdd2d1a91059fcbaa5a33fda622525