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

Robert Sparks <rjsparks@nostrum.com> Wed, 05 April 2017 20:47 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: ietf@ietf.org
Delivered-To: ietf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9411294AF; Wed, 5 Apr 2017 13:47:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
To: <secdir@ietf.org>
Cc: draft-ietf-httpbis-encryption-encoding.all@ietf.org, ietf@ietf.org, ietf-http-wg@w3.org
Subject: Secdir last call review of draft-ietf-httpbis-encryption-encoding-08
X-Test-IDTracker: no
X-IETF-IDTracker: 6.49.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149142527327.21912.5654685591478038284@ietfa.amsl.com>
Date: Wed, 05 Apr 2017 13:47:53 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/2b60awtoPaUy64Dpn4iamBIz1ak>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Apr 2017 20:47:53 -0000

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