LoST: A Location-to-Service Translation Protocol
Note: This ballot was opened for revision 07 and is now closed.
( Sam Hartman ) Discuss
Discuss (2008-03-06 for -)
Section 18 claims that authorization is not generally required. I agree that LOST servers do not typically need to authorize clients, but authentication and authorization of LOST servers by clients seems critical to the security of the system. Please clarify the text. [Ted's proposed clarification is fine] This spec proposes that RFC 2818 be used to describe how TLS certificates are validated. However let's think about how LOST works. I get some identifier L from a secure source--static configuration of my domain. I look up L as a NAPTR record. I get a URI, and then apply the rules of RFC 2818 to it. What secures the translation from L to the URI? You could argue dnssec, but I don't think that is a practical suggestion for today's internet and LOST clients. So, it seems that as specified LOST has a very significant attack on server authentication and authorization. I think that RFC 2818 is an inappropriate mapping of how to use TLS for LOST. The easiest way to handle this is to require that L (the string configured in DNS) appear in the TLS certificate. I'm not sure that doing so is compatible with the https URI scheme, nor am I sure that most HTTPs stacks will easily support implementing this. However I'm sure this problem is very important to solve. Note that if dnssec is actually used, then the mechanism as specified is fine.
Comment (2008-03-05 for -)
I'd really like to see some thought applied to RFC 3205 and this protocol. Especially given that the security requirements do not seem to line up well with RFC 2818, I'm not at all convinced that the requirements of RFC 3205 are met.
( Lisa Dusseault ) (was Discuss) Yes
( Jon Peterson ) Yes
Jari Arkko No Objection
Comment (2008-03-05 for -)
> <path>elelment, Typo.
( Ron Bonica ) No Objection
( Ross Callon ) No Objection
( Pasi Eronen ) (was Discuss) No Objection
( Russ Housley ) (was Discuss) No Objection
Comment (2008-02-19 for -10)
As pointed out by Ben Campbell in his Gen-ART Review, these things should probably be reworded as normative statements: - Section 5.2, last paragraph: "... it is the responsibility of the client to check the 'expires' attribute... " - Section 6, paragraph 3: "If a query is answered iteratively, the querier includes all servers that it has already contacted." - Section 8.3.1: "The order of location elements is significant; the server uses the first location element where it understands the location profile."
( Cullen Jennings ) (was Discuss) No Objection
( Tim Polk ) (was No Record, Discuss, No Objection) No Objection
( Dan Romascanu ) No Objection
Comment (2008-03-04 for -)
1. second paragraph of Section 1 - PIDF-LO is duplicated 2. second paragraph of Section 1 - please explain what are "2-1-1" and "3-1-1" services. Maybe this is common knowledge in the US, but for a non-American reader they have no significance. Better describe the service for example 'non-emergency municipal services or a citizen community services (e.g. "3-1-1" in the United States', etc. 3. in section 13.2 - I doubt that the three MAY in the descriptions of the warnings are appropriate. If I am not mistaken if each of the warning conditions is met in particular, including the earning message in the response is not optional. 4. Reference  has a corrupted content at the time I am writing this comment. This makes me wonder wheter a better protected place can be found for the on-line examples quoted in Appendix B.
( Mark Townsley ) No Objection
( Magnus Westerlund ) No Objection
Comment (2008-02-20 for -)
Abtract: Usage of "PSAP" acronym. Please write it out.