LoST: A Location-to-Service Translation Protocol
RFC 5222
Discuss
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
(Sam Hartman; former steering group member) Discuss
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.
(Jon Peterson; former steering group member) Yes
(Lisa Dusseault; former steering group member) (was Discuss) Yes
(Cullen Jennings; former steering group member) (was Discuss) No Objection
(Dan Romascanu; former steering group member) No Objection
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 [21] 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.
(Jari Arkko; former steering group member) No Objection
> <path>elelment, Typo.
(Magnus Westerlund; former steering group member) No Objection
Abtract: Usage of "PSAP" acronym. Please write it out.
(Mark Townsley; former steering group member) No Objection
(Pasi Eronen; former steering group member) (was Discuss) No Objection
(Ron Bonica; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
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."
(Tim Polk; former steering group member) (was No Record, Discuss, No Objection) No Objection