IETF Logo Mail Archive

Re: [Trans] TRANS Draft minutes for IETF-93

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 05 August 2015 20:57 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A0F1A916C for <trans@ietfa.amsl.com>; Wed, 5 Aug 2015 13:57:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 S-HHDnrultMl for <trans@ietfa.amsl.com>; Wed, 5 Aug 2015 13:57:08 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 277E31A8982 for <trans@ietf.org>; Wed, 5 Aug 2015 13:57:08 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id D83DAF984; Wed, 5 Aug 2015 16:57:06 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 8114E2005D; Wed, 5 Aug 2015 22:56:56 +0200 (CEST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Ben Laurie <benl@google.com>, "Salz, Rich" <rsalz@akamai.com>, "trans@ietf.org" <trans@ietf.org>
In-Reply-To: <CABrd9STqHqZj6Kq1m+17bznXLZee8bPvYrd3qCpk-p5Lo29dHQ@mail.gmail.com>
References: <9ed3e1bb8b1549fd8f87eb327360e9b9@ustx2ex-dag1mb2.msg.corp.akamai.com> <CABrd9STqHqZj6Kq1m+17bznXLZee8bPvYrd3qCpk-p5Lo29dHQ@mail.gmail.com>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Wed, 05 Aug 2015 16:56:56 -0400
Message-ID: <87fv3xzc6f.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/5-ywaiZTF_yspKHBc2O4N300P9c>
Subject: Re: [Trans] TRANS Draft minutes for IETF-93
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2015 20:57:10 -0000

On Fri 2015-07-24 07:28:53 -0400, Ben Laurie wrote:
> On Thu, 23 Jul 2015 at 20:59 Salz, Rich <rsalz@akamai.com> wrote:
>> Steve raised issue of exposing what certs a client is interested in if
>> size of get-entries can shrink to one, for example.
>
> My response was omitted: this doesn't matter so long as the client
> continues to request entries until it has all the ones it originally
> decided to fetch.

as a concrete example, if a client says "give me entries from 1000 to
2000" while knowing it actually only wants entry 1223, and the server
dribbles them back one at a time instead of 1000 at a time, then the
client which stops at 1223 has effectively lost privacy.

If the client continues with the next 777 fetches anyway, then it should
be identical privacy-wise to the initial request (albeit at a likely
higher expense in terms of latency and network traffic)

       --dkg

v2.23.0 | Report a Bug | By Email