The LoST-Validation Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag
draft-gellens-lost-validation-09

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.

I have nothing to add to Rob's comments...

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.

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