Re: [secdir] Secdir last call review of draft-ietf-httpbis-encryption-encoding-08

Robert Sparks <rjsparks@nostrum.com> Thu, 06 April 2017 14:47 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A6F1294B9; Thu, 6 Apr 2017 07:47:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MZ4NyIdU-QA; Thu, 6 Apr 2017 07:47:13 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDA8C129457; Thu, 6 Apr 2017 07:47:13 -0700 (PDT)
Received: from unescapeable.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v36ElBKd026308 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 6 Apr 2017 09:47:12 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be unescapeable.local
To: Martin Thomson <martin.thomson@gmail.com>
References: <149142527327.21912.5654685591478038284@ietfa.amsl.com> <CABkgnnU7qXVeCDxoRbG8i6GbxJTA6gRpyHH0Yf+h0eRAJ+WLxw@mail.gmail.com>
Cc: "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-httpbis-encryption-encoding.all@ietf.org, "ietf@ietf.org" <ietf@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <1f550ddb-a279-ad2b-0599-c9ed2c95da09@nostrum.com>
Date: Thu, 6 Apr 2017 09:47:08 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CABkgnnU7qXVeCDxoRbG8i6GbxJTA6gRpyHH0Yf+h0eRAJ+WLxw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/6TCbjRD3sEBNmZxEhxN7Q4LA0aI>
Subject: Re: [secdir] Secdir last call review of draft-ietf-httpbis-encryption-encoding-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Apr 2017 14:47:15 -0000


On 4/5/17 5:32 PM, Martin Thomson wrote:
> On 6 April 2017 at 06:47, Robert Sparks <rjsparks@nostrum.com>; wrote:
>> 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.
> 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.
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.
>
> 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.
That would be my personal preference.