[Dots] Benjamin Kaduk's Yes on draft-ietf-dots-signal-channel-31: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dots-signal-channel-31: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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).