Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification
draft-ietf-dots-signal-channel-41

Note: This ballot was opened for revision 31 and is now closed.

Benjamin Kaduk Yes

Comment (2019-04-02 for -31)
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).

Deborah Brungard No Objection

Alissa Cooper (was Discuss) No Objection

Comment (2019-05-10 for -33)
Thanks for addressing my DISCUSS and COMMENT.

(Suresh Krishnan) (was Discuss) No Objection

Comment (2019-05-21 for -34)
Thanks for addressing my DISCUSS.

Warren Kumari No Objection

Comment (2019-05-01 for -31)
No email
send info
I support Mirja and Alexey's DISCUSS positions.

(Mirja Kühlewind) (was Discuss) No Objection

Comment (2019-12-20 for -40)
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?

Barry Leiba No Objection

Comment (2019-05-01 for -31)
No email
send info
Alexey has this document well covered; nothing to add.

(Alexey Melnikov) (was Discuss) No Objection

Comment (2019-05-18 for -34)
No email
send info
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.

Alvaro Retana No Objection

(Adam Roach) (was Discuss) No Objection

Comment (2019-05-09 for -32)
No email
send info
Thanks for addressing my DISCUSS points.

Éric Vyncke No Objection

Comment (2019-05-01 for -31)
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)
No email
send info
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 …”?