This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. From the perspective of the transport area, this document is Ready: the specification of new SRV application protocol names appears to comply with current TSVART guidance. That said, I have some questions and comments that may or may not be of interest to the transport ADs: * Section 4 says: The discovery method is reiterated by a DOTS agent upon the following events: o Expiry of a a validity timer (e.g., DHCP lease, DNS TTL) associated with a discovered DOTS agent. From my reading, rendezvous information for the DOTS server is "pushed" to the client via DHCP, so it's not clear the above is actionable. Is it simply the case that a client should use the DOTS server assigned in the most recent lease? * Section 5.1 describes a trust mechanism that can charitably be described as "hopeful". Fundamentally, the security of TLS relies on a three-legged stool: (1) The integrity of the X.509 server certificate issuance procedures (2) The cryptographic trust anchors configured in a client (3) Pre-established trust in the server's identity, which must match a ServerAltName in the signed server certificate The security considerations section briefly alludes to the problems with using DHCP via reference to security considerations sections in DHCP RFCs, but I don't think that quite does justice to the problem here. TLS is cripped by a failure in any of the above: * A trusted CA wrongly issues a certificate to a third party with the ability to hijack rendezvous (e.g., through BGP or DNS attacks) * A user's certificate store is augmented by a CA under the control of an adversary * Via a mistaken or injected hostname, a user establishes a connection to the wrong endpoint that nonetheless has a legitimately-issued certificate Using DHCP, an inherently insecure protocol, to inform DOTS clients of the hostname of DOTS server knocks this third leg out, calling into question the entire mechanism. Measures can be taken to mitigate this risk, such as configuring clients with a domain whitelist (e.g., accept DOTS names only within a particular domain), configuring clients with a set of private CAs as trust anchors, configuring border routers with network-layer packet filtering for DOTS traffic, etc., but ultimately without some preconfiguration, clients are at the mercy of rogue DHCP. * Section 5.2.1 has: The DHCPv4 [RFC2132] DOTS Reference Identifier option is used to configure a name of the peer DOTS agent. The format of this option is illustrated in Figure 6. Code Length Peer DOTS agent name +-----+-----+-----+-----+-----+-----+-----+-- |TBA3 | n | s1 | s2 | s3 | s4 | s5 | ... +-----+-----+-----+-----+-----+-----+-----+-- The values s1, s2, s3, etc. represent the domain name labels in the domain name encoding. Is the final label zero-length? Other parts of the DHCPv4 protocol terminate domain names with a zero-length label. What if a zero-length label appears in some s_i other than the final one? * Section 7 says: This document does not define any keys; the TXT record of a DNS-SD service is thus empty (Section 6 of [RFC6763]). RFC 6763 says that an empty TXT record MUST be included alongside the SRV record where DNS-SD is concerned. Should normative language be used here, or should we rely on the normative reference in case that guidance changes in the future?