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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 02 Mar 2022 06:10:54 -0800

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.

---

From: Brian Rosen <[email-masked]>
Date: Wed, 2 Mar 2022 09:23:29 -0500

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 <[email-masked]> wrote:
>

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 2 Mar 2022 14:31:10 +0000

Hi Brian!

> -----Original Message-----
> From: Brian Rosen <[email-masked]>
> Sent: Wednesday, March 2, 2022 9:23 AM
> To: Roman Danyliw <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; ecrit-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Roman Danyliw's No Objection on draft-ietf-ecrit-similar-location-
> 18: (with COMMENT)
> 
> 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”

Thanks for explaining the deployment context.  The above proposed text captures my thinking.  Much appreciated.

Regards,
Roman

> > 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-posi
> > tions/ for more information about how to handle DISCUSS and COMMENT
> > positions.
> >
> >
> > ** 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.
> >
> >
> >

---

From: "Randall Gellens" <[email-masked]>
Date: Wed, 02 Mar 2022 11:14:38 -0800

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:

> 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
>
>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>> schema
>> that the
>> correct