Re: [alto] Eric Rescorla's Discuss on draft-ietf-alto-multi-cost-08: (with DISCUSS)

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Wed, 12 April 2017 13:53 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F471294C0 for <alto@ietfa.amsl.com>; Wed, 12 Apr 2017 06:53:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 XGPWQYRZ5eh0 for <alto@ietfa.amsl.com>; Wed, 12 Apr 2017 06:53:02 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 838DC1294BE for <alto@ietf.org>; Wed, 12 Apr 2017 06:53:01 -0700 (PDT)
Received: (qmail 23914 invoked from network); 12 Apr 2017 15:46:19 +0200
Received: from p5dec24e1.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.36.225) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Apr 2017 15:46:19 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <149195174602.15710.12028453376853096422.idtracker@ietfa.amsl.com>
Date: Wed, 12 Apr 2017 15:46:17 +0200
Cc: The IESG <iesg@ietf.org>, alto-chairs@ietf.org, draft-ietf-alto-multi-cost@ietf.org, alto@ietf.org, ietf@j-f-s.de
Content-Transfer-Encoding: quoted-printable
Message-Id: <AEFDD971-D30C-4F40-A559-B163F6569246@kuehlewind.net>
References: <149195174602.15710.12028453376853096422.idtracker@ietfa.amsl.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/b7lVnJ7SfH6iS_1vhMsScQXE6Ys>
Subject: Re: [alto] Eric Rescorla's Discuss on draft-ietf-alto-multi-cost-08: (with DISCUSS)
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Apr 2017 13:53:03 -0000

Hi Ekr,

I think the threat below can easily mitigated by not using multi-query because that’s a client side decisions. It’s probably good to anyway document the risk described below so clients are aware of it and can make an informed decision to use multi-query or not. Can you maybe proposed 2-3 sentences to be added to address your discuss?

Thanks,
Mirja


> Am 12.04.2017 um 01:02 schrieb Eric Rescorla <ekr@rtfm.com>:
> 
> Eric Rescorla has entered the following ballot position for
> draft-ietf-alto-multi-cost-08: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-alto-multi-cost/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> This document states:
> "This document does not introduce any privacy or security issues not
>   already present in the ALTO protocol."
> 
> This may be true, but it's not obvious it is, because when questions are
> asked together, that's more of a privacy signature than independently.
> So, suppose that application A asks for metric A and application B asks
> for metric B and application C asks for A and B. If these applications
> are mixed behind a CGN, with single queries then you don't know whether
> you have some A clients and some B clients, but if you do multi-query,
> it's clear these are C clients. This is a potentially serious issue if
> (for instance) Bittorrent always asks for a very distinguished set of
> parameters, so an ALTO server might use this to find Bittorrent clients.
> 
> 
> 
>