Note: This ballot was opened for revision 31 and is now closed.
I am balloting YES but noticed a few things in the -31 that can get addressed with the rest of the IESG comments. Section 4.4.1 Implementations SHOULD set 'cuid' to the output of a cryptographic [...] [RFC6234]. The output of the cryptographic hash algorithm is truncated to 16 bytes; truncation is done by stripping off the final 16 bytes. The truncated output is base64url encoded. [...] If a DOTS client has to change its 'cuid' for some reason, it MUST NOT do so when mitigations are still active for the old 'cuid'. The 'cuid' SHOULD be 22 characters to avoid DOTS signal message fragmentation over UDP. [...] We need to cite RFC 4648, Section 5, for base64url. Also, getting a 22-character base64url-encoded cuid requires stripping the trailing '=' from the encoding, and we should explicitly say to do that. A similar attack can be achieved by a compromised DOTS client which can sniff the TLS 1.2 handshake, use the client certificate to identify the 'cuid' used by another DOTS client. This attack is not possible if algorithms such as [RFC4122] are used to generate the 'cuid'. [...] I think the key part of RFC4122 cuid generation (w.r.t. preventing sniffing) is that it's non-deterministic (and thus non-guessable), so we should say something like "because such UUIDs are not a deterministic function of the client certificate". Figure 11 needs to show the response that indicates a conflicting cuid that triggers the second request. Section 10 When FQDNs are used as targets, the DOTS server MUST rely upon DNS privacy enabling protocols (e.g., DNS over TLS [RFC7858], DoH [RFC8484]) to prevent eavesdroppers from possibly identifying the target resources protected by the DDoS mitigation service and means to ensure the target FQDN resolution is authentic (e.g., DNSSEC [RFC4034]). nits: "DNS over TLS or DoH" ("or" instead of comma, but keep the references as-is); comma before "and means to ensure", since the DOTS server has to do both of those (as opposed to the DOTS server using DoT/DoH which provides both eavesdropping protection and data authenticity, which is what the current text says).
Thanks for addressing my DISCUSS and COMMENT.
Thanks for addressing my DISCUSS.
I support Mirja and Alexey's DISCUSS positions.
Thanks a lot for addressing my many discuss points and all the additional work that went into this spec! ------------------- OLD COMMENTS (for the record as I didn't check anymore if they have been addressed or not): 1) I really recommend to add subsections to section 4.4.1. 2) section 4.4.1: "The lifetime of the deactivated mitigation request will be updated to (retry-timer + 45 seconds), so the DOTS client can refresh the deactivated mitigation request after retry-timer seconds before expiry of lifetime and check if the conflict is resolved." This wording is not fully clear to me. If the life time of a deactivated request in updated, isn't it active again? And if it is active and another request is sent, isn't that request rejected again. Can you please further clarify. 3) section 4.4.2: "lifetime: The remaining lifetime of the mitigation request, in seconds." Shouldn't lifetime we rather a timestamp because there is some unknown transmission delay between the time when the reply is generated and the reply is received, and as such a lifetime in seconds is quite meaningless for the client. 4) section 22.214.171.124: " For DOTS server application, the message type MUST always be set to Non-confirmable even if the underlying COAP library elects a notification to be sent in a Confirmable message." I'm not sure I understand this sentence. Can you please further explain? 5) section 4.4.4: "For example, if there is a financial relationship between the DOTS client and server domains, the DOTS client stops incurring cost at this point." I find this sentence a bit problematic given the active-but-terminating period is defined by server. Wouldn't that mean the server can make me pay for undefined period of time? Also the max of 300 sec doesn't seem to be a MUST...? 6) In section Section 4.5 you talk about Caop Ping/Pong. However, these terms are not used in RFC7252. Maybe clarify that empty confirmable messages are used and provide a pointer to section 4.2. of RFC7252 right here (instead of only later). 7) High-level question: Given this doc specifies a YANG model, why are configuration are not retrieved and changed using NETCONF or RESTCONF?
Alexey has this document well covered; nothing to add.
126.96.36.199. Registration Template Registration requests for the 0x4000 - 0x7FFF range are evaluated after a three-week review period on the dots-signal-reg- firstname.lastname@example.org mailing list, Responsible AD should make sure that the mailing list exists before this document is published. on the advice of one or more Designated Experts.
Thanks for addressing my DISCUSS points.
No objection on my part but I support Suresh's DISCUSS (also shared by Mirja and Adam).
Full Disclosure. I was the WG co-chair when this draft was developed. Based on feedback, I'm changing my ballot from No Objection to Recuse to remove any perceived COI. A few minor items: (1) Typos: Section 3: s/signalling/signaling/ Section 4.4.1: s/implictily/implicitly/ (2) Section 7.1, Per “The DOTS client additionally uses [RFC6125] validation techniques to compare the domain name with the certificate provided”, this sentence appears to be missing a RFC2119 word – should it read something like “Additionally, the DOTS client MUST use [RFC6125] validation …”?