Re: [Dots] additional remaining items for draft-ietf-dots-signal-channel-31

[Benjamin Kaduk <[e-mail]>]

On Fri, Jun 28, 2019 at 05:21:24PM -0500, Benjamin Kaduk wrote:
> Hi Mirja,
> 
> I wanted to check in with the status of the remaining Discuss points for
> this document.  I tried to go through the previous discussions and have
> made my own analysis of where things stand, so hopefully we can compare
> notes.

In addition to Mirja's pending Discuss position, there are some other
points that we should probably update in the document from other IESG
review comments.

I still need to ensure that the [e-mail] list exists
in time for it to be used for registration requests.

The order of the If-Match: and Content-Format: header fields changed
between the -31 and the -34; is that order important?

Section 4.7 added text:

   If the DOTS server receives traffic from the peer DOTS client (e.g.,
   peer DOTS client initiated heartbeats) but maximum 'missing-hb-
   allowed' threshold is reached, the DOTS server MUST NOT consider the
   DOTS signal channel session disconnected.  The DOTS server MUST keep
   on using the current DOTS signal channel session so that the DOTS
   client can send mitigation requests over the current DOTS signal
   channel session.  In this case, the DOTS server can identify the DOTS
   client is under attack and the inbound link to the DOTS client
   (domain) is saturated.  Furthermore, if the DOTS server does not
   receive a mitigation request from the DOTS client, it implies the
   DOTS client has not detected the attack or, if an attack mitigation
   is in progress, it implies the applied DDoS mitigation actions are
   not yet effective to handle the DDoS attack volume.

Is the server supposed to start mitigation when it identifies that the
client is under attack but the client has not requested mitigation?

RFC 8305 needs to be normative since we use its rules for connection
attempts.

I still think that section 6 (in addition to the current "Note:
implementors must check" text) should specifically call out that the CBOR
and JSON types for enumerateds and the 64-bit quantities can differ in
surprising ways depending on the encoder used, as a potential hazard to use
caution with.

Section 4.4.1 lists a recommended procedure for 'cuid' generation:

         For the reasons discussed in Appendix A, implementations SHOULD
         set 'cuid' to the output of a cryptographic hash algorithm
         whose input is the Distinguished Encoding Rules (DER)-encoded
         Abstract Syntax Notation One (ASN.1) representation of the
         Subject Public Key Info (SPKI) of the DOTS client X.509
         certificate [RFC5280], the DOTS client raw public key
         [RFC7250], or the "Pre-Shared Key (PSK) identity" used by the
         DOTS client in the TLS ClientKeyExchange message.  In this
         version of the specification, the cryptographic hash algorithm
         used is SHA-256 [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 (Section 5 of [RFC4648]) with the trailing
         "=" removed from the encoding.

In the ballot discussion we heard that all parts of this are just
recommendations (i.e., there is no requirement to base64 or strip padding
or use SHA-256, etc.).  This could perhaps be clarified by changing to:

    For the reasons discussed in Appendix A, implementations SHOULD set 'cuid'
    using the following procedure: first, the Distinguished Encoding Rules
    (DER)-encoded Abstract Syntax Notation One (ASN.1) representation of the
    Subject Public Key Info (SPKI) of the DOTS client X.509 certificate
    [RFC5280], the DOTS client raw public key [RFC7250], or the "Pre-Shared Key
    (PSK) identity" used by the DOTS client in the TLS ClientKeyExchange
    message is input to the SHA-256 [RFC6234] cryptographic hash.  Then,
    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 (Section 5 of [RFC4648]) with the
    trailing "=" removed from the encoding, and the resulting value used as
    the 'cuid'.

which makes very clear that the "SHOULD" applies to the entire procedure,
and not just to the "output of a cryptographic hash algorithm" with the
normativity of the other steps being less well specified.  (This also
inlines the use of SHA-256, since this is the only specification we're
talking about.)

Mirja had a note about the retry-timer and the 45-second addition.  IIUC
the mitgation remains deactivated for the entire retry-timer plus 45
seconds and then is deleted afterwards, but I think Mirja would still like
that behavior clarified in the text.

The ballot discussions indicated that we needed some text about using
Non-Confirmable messages because that overrides behavior in RFC 7641; we
should be more explicit that we are overriding that behavior.

The question of whether the active-but-terminating period is hard-capped at
300 seconds seems to remain unanswered.

In section 4.5 the mention of CoAP ping/pong was removed but no
clarification or pointer to 7252 section 4.2 was added (which was requested
by one of the reviews).

There's also a couple typos left:

s/implictily/implicitly/

s/10 mn/10 min/

Thanks for all the great work getting this document over the finish line!

-Ben