Re: [Ecrit] Roman Danyliw's No Objection on draft-ietf-ecrit-similar-location-18: (with COMMENT)

Randall Gellens <rg+ietf@coretechnologyconsulting.com> Wed, 02 March 2022 20:44 UTC

Return-Path: <rg+ietf@coretechnologyconsulting.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878583A0D1C; Wed, 2 Mar 2022 12:44:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 kmb89I1NID0z; Wed, 2 Mar 2022 12:44:35 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id E81293A0CC5; Wed, 2 Mar 2022 12:44:34 -0800 (PST)
Received: from [99.111.97.171] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 2 Mar 2022 11:14:39 -0800
From: Randall Gellens <rg+ietf@coretechnologyconsulting.com>
To: Brian Rosen <br@brianrosen.net>
Cc: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>, draft-ietf-ecrit-similar-location@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, dwightpurtle@gmail.com
Date: Wed, 02 Mar 2022 11:14:38 -0800
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <67076D06-7B20-41FE-9263-9BC87DD3D916@coretechnologyconsulting.com>
In-Reply-To: <0C760307-44DB-405D-A93D-AAB69D674361@brianrosen.net>
References: <164623025433.17954.9445129257215162877@ietfa.amsl.com> <0C760307-44DB-405D-A93D-AAB69D674361@brianrosen.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/d8f11cWWRLLrIEN1vlDLwX84psI>
Subject: Re: [Ecrit] Roman Danyliw's No Objection on draft-ietf-ecrit-similar-location-18: (with COMMENT)
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Emergency Context Resolution with Internet Technologies <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Mar 2022 20:44:41 -0000

If the database is not confidential, then what's the risk of exposure 
via repeated partial queries? Rate limiting can be useful to avoid 
denial of service, of course. Would text such as the following be more 
appropriate?

    In cases where a LoST database contains confidential information,
    the similar location service could be misused to attempt to
    enumerate the entire database by running a high volume of invalid
    or partial queries. A LoST server may limit the volume of similar
    locations it returns. It may also authenticate queries and limit
    similar location or other services to known queriers.

--Randall

On 2 Mar 2022, at 6:23, Brian Rosen wrote:

> Thanks for the comments.  It’s a W3C schema, and I will add text to 
> say that.
>
> The suggestion to limit query rate for corrections is a good one, and 
> I’ll add it.  The database should be public, but the users who 
> really need correction service (typically communications service 
> providers) are typically known in advance and authentication could 
> differentiate.
>
> “The similar location service could be misused to attempt to 
> enumerate the entire database by running a high volume of invalid or 
> partial queries.  The LoST server can limit the volume of similar 
> locations it returns.  It can also authenticate queries and limit the 
> service to known queriers”
>
> Brian
>
>> On Mar 2, 2022, at 9:10 AM, Roman Danyliw via Datatracker 
>> <noreply@ietf.org> wrote:
>>
>> Roman Danyliw has entered the following ballot position for
>> draft-ietf-ecrit-similar-location-18: No Objection
>>
>> 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/about/groups/iesg/statements/handling-ballot-positions/
>> for more information about how to handle DISCUSS and COMMENT 
>> positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-location/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Thank you to Scott Kelly for the SECDIR review.
>>
>> ** Section 6.  This document should have a normative reference to the 
>> schema
>> format used in this section.  Is that RELAX NG? or W3 Schema?  I’ll 
>> note that
>> [I-D.ietf-ecrit-lost-planned-changes] also doesn’t normatively 
>> reference a
>> schema format.
>>
>> ** Section 7.  Given the deployment models of LoST, is it expected 
>> that the
>> entire contents of the server database would be publicly available?  
>> Would it
>> be an issue if large portions of the LoST back-end database (on the 
>> LoST
>> server) were revealed?  I ask because if the server is willing to 
>> correct
>> input/provide suggestions based on partial on invalid client input, a 
>> malicious
>> party could potentially use this to enumerate the database via high 
>> volume of
>> invalid/partial queries. If that’s a threat, then perhaps there 
>> should be a
>> form for rate limiting applied on the number of corrected queries 
>> permitted per
>> unit time.
>>
>>
>>