Subject: [secdir] secdir review of draft-forte-lost-extensions-06.txt

From: Carl Wallace <[email-masked]>
Date: Fri, 05 Aug 2011 16:28:33 -0400

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments
just like any other last call comments.

This draft defines extensions to the LoST protocol defined in RFC 5222.
Where RFC 5222 focuses on emergency services.  This draft addresses usage
of the protocol for non-emergency services.  The draft adds three new
types of <findService> queries: N nearest, within distance X and servedBy.
 The security considerations section is very brief and primarily addresses
potential problems with a LOST server that provides emergency and
non-emergency service support being over loaded by non-emergency requests.
 A few additional concerns that may warrant mention in the document are
below.

Privacy is not mentioned in this draft at all.  RFC 5222 mentions using
HTTP over TLS.  Queries for some types of non-emergency services may raise
privacy concerns not associated with seeking emergency services.
Similarly, the draft does not mention integrity.  The lack of privacy or
integrity for responses residing in a cache may be worth mentioning as
well. 

The draft does not discuss error handling at all.  Some types of errors
associated with the extensions do not seem to fit into the errors
described in RFC 5222.  For example, could a server return an error when a
requested area was too large for a query?  Is the server allowed to place
its own limits less than a client requests?  These concerns may not arise
in 
the 5222 context, where non-overlapping service regions are a mitigation.

Given the commercial focus of the draft, the potential for stale
information to be returned by a server seems high and probably worth a
mention.  For example, a pizza service may have closed.

Services are identified by URN.  RFC 5222 uses URNs defined in RFC 5031,
which does not apply here.  Who manages the URNs for this draft?  It's
worth noting the examples within this draft use different URNs to
reference the important pizza service.

A few nits, on page 11 correct "consinstent".  Also the next to last
paragraph on page 11 is a little difficult to parse.

---

From: Carl Wallace <[email-masked]>
Date: Tue, 9 Aug 2011 12:55:16 -0400

A few responses are inline.  Generally your responses are fine but I think
including your thoughts in the draft would be helpful.

On Tue, Aug 9, 2011 at 12:33 PM, Andrea G. Forte <[email-masked]> wrote:

> <snip>
> [AGF]
> I am not convinced we need additional error messages.
> Generally speaking, I do not think the draft should limit what the server
> can do with its content. Given a large area, a server could decide to
> return the highest rated POIs only, or perhaps a fixed subset, or all of
> them. I do not think that we can classify such behaviors as LoST errors.
> These seem to be policy issues rather than errors.
>
> [CW] It doesn't seem necessarily true to me that the extensions do not
introduce new error conditions, but highlighting the expectation that a
server can adjust a request in order to provide service would be helpful.
 Does there need to be some means for the server to indicate to the client
that there may be some additional related responses that can't be retrieved
using the provided request?  If not, it seems like there may be some blind
spots for some queries.

> [AGF]
> This draft addresses extensions to the protocol used to convey information
> about location-based services. The way this information is maintained is
> out of scope.
> Similarly, for emergency services, if the boundaries of a PSAP change they
> have to be updated in the DB used by the LoST server. The way these are
> updated is not in the scope of RFC5222.
>
> [CW]
My point was the information is likely more volatile in the commercial
context and noting this is worthwhile since the issues probably does not
arise (at least as frequently) in the RFC 5222 context.  As with the others,
it seems worth noting somewhere even if the way the update is performed is
out of scope.

> <snip>

---

From: "Andrea G. Forte" <[email-masked]>
Date: Tue, 09 Aug 2011 12:33:41 -0400

Carl,

Thank you for your review. Please read comments inline.

-Andrea

>integrity for responses residing in a cache may be worth mentioning as

[AGF]
As this draft was meant to add functionalities to the LoST protocol (hence
the 'extensions' in the name), I assumed that it was clear that everything
else mentioned in RFC5222 and not mentioned in our draft would still
stand. However, to make this more clear, I have added a paragraph in the
Security section to address your concerns.

[AGF]

[AGF]

>reference the important pizza service.

[AGF]
We have submitted a draft on this very issue in the past and encountered
some resistance. Other people in the IETF thought we should leave this
issue to experts in other non-IETF bodies. We are now trying to resume
such work.
(http://tools.ietf.org/html/draft-forte-ecrit-service-classification-03)

>paragraph on page 11 is a little difficult to parse.

[AGF]
Thanks.