Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification
draft-ietf-dots-signal-channel-41
Yes
No Objection
(Alvaro Retana)
(Deborah Brungard)
Recuse
Note: This ballot was opened for revision 31 and is now closed.
Warren Kumari
No Objection
Comment
(2019-05-01 for -31)
Not sent
I support Mirja and Alexey's DISCUSS positions.
Éric Vyncke
No Objection
Comment
(2019-05-01 for -31)
Sent
No objection on my part but I support Suresh's DISCUSS (also shared by Mirja and Adam).
Roman Danyliw
(was No Objection)
Recuse
Comment
(2019-05-02 for -31)
Sent for earlier
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 …”?
Benjamin Kaduk Former IESG member
Yes
Yes
(2019-04-02 for -31)
Sent
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).
Adam Roach Former IESG member
(was Discuss)
No Objection
No Objection
(2019-05-09 for -32)
Sent for earlier
Thanks for addressing my DISCUSS points.
Alexey Melnikov Former IESG member
(was Discuss)
No Objection
No Objection
(2019-05-18 for -34)
Sent for earlier
9.6.1.1. Registration Template
Registration requests for the 0x4000 - 0x7FFF range are evaluated
after a three-week review period on the dots-signal-reg-
review@ietf.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.
Alissa Cooper Former IESG member
(was Discuss)
No Objection
No Objection
(2019-05-10 for -33)
Sent
Thanks for addressing my DISCUSS and COMMENT.
Alvaro Retana Former IESG member
No Objection
No Objection
(for -31)
Not sent
Barry Leiba Former IESG member
No Objection
No Objection
(2019-05-01 for -31)
Not sent
Alexey has this document well covered; nothing to add.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -31)
Not sent
Mirja Kühlewind Former IESG member
(was Discuss)
No Objection
No Objection
(2019-12-20 for -40)
Sent
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 4.4.2.1: " 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?
Suresh Krishnan Former IESG member
(was Discuss)
No Objection
No Objection
(2019-05-21 for -34)
Sent
Thanks for addressing my DISCUSS.