The LoST-Validation Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag
RFC 8917
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
Alvaro Retana No Objection
Erik Kline No Objection
Martin Duke No Objection
Murray Kucherawy No Objection
Robert Wilton No Objection
Hi,
Thanks for this document, with no domain specific knowledge I was able to easily understand the problem being solved and the solution.
My only observation is that I found section 3 perhaps a little bit repetitive. In particular I noted:
3. The LoST-Validation Application Service Tag
In order to permit separability
of the mapping and validation services performed using LoST, and to
reduce the likelihood of a client requiring location validation
reaching servers unwilling to do so, this document defines the 'LoST-
Validation' service tag.
This sentence seems to somewhat repeat what is stated in the first paragraph of section 3, so I wasn't sure whether it was required.
The discovery procedure
with the 'LoST-Validation' service tag might result in the same URL
as the 'LoST' service tag, or it may result in a different URL. When
the URLs are different, they could lead to the same physical servers,
or different servers.
Similarly, this sentence seems to somewhat overlap with the text in the second paragraph of section 3, and the content could potentially be incorporated into the second paragraph.
Regards,
Rob
Roman Danyliw No Objection
This draft is a limited scope update to RFC5222. As such, I am balloting this feedback as a COMMENT since I appreciate that the base document (RFC5222) (and associated security considerations section) was written in a different era. ** RFC5222 noted that “The use of server identity does leave open the possibility of DNS- based attacks, as the NAPTR records may be altered by an attacker. The attacks include, for example, interception of DNS packets between the client and the recursive name server, DNS cache poisoning, and intentional modifications by the recursive name server; … particularly when they are requesting NAPTR records in environments where the local recursive name server, or the network between the client and the local recursive name server, is not considered trustworthy.” We now have mitigations for some of these threats by using encrypted DNS (i.e., DNS over TLS or DoH). Please provide a reference to them and consider whether it is appropriate to providing some level of normative language prescribing their use. ** RFC5222 also noted that “An attacker that can eavesdrop on the communication requesting this lookup can surmise the existence of an emergency and possibly its nature, and may be able to use this to launch a physical attack on the caller”. This language is the closest text I could find when skimming for privacy considerations/pervasive monitoring issues. It seems like this topic should have explicit treatment.
Warren Kumari No Objection
I have nothing to add to Rob's comments...
Éric Vyncke No Objection
(Barry Leiba; former steering group member) Yes
(Alissa Cooper; former steering group member) No Objection
(Benjamin Kaduk; former steering group member) No Objection
I echo Roman's comments (and sentiment regarding the history/origin of the protocol). Additionally, since in some sense we are defining a new protocol with the LoST-Validation service tag, we should consider whether or not it is desirable and/or appropriate to require the use of HTTPS, prohibiting unencrypted+unauthenticated HTTP. For LoST mapping, used in emergency call services, it seems fairly natural to prefer availability over authentication and allow unencrypted HTTP. Since LoST validation is "typically performed in advance", though, it is less clear to me that there are clear reasons to allow unencrypted HTTP in that usage.
(Deborah Brungard; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection