Re: [Dots] AD review of draft-ietf-dots-signal-channel-25 (2nd Part)

[<[e-mail]>]

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:[e-mail]]
> Envoyé : mercredi 16 janvier 2019 01:14
> À : [e-mail]
> Cc : [e-mail]
> Objet : AD review of draft-ietf-dots-signal-channel-25
> 
> 
> Section 4.4
> 
>    GET:    DOTS clients may use the GET method to subscribe to DOTS
>            server status messages, or to retrieve the list of its
>            mitigations maintained by a DOTS server (Section 4.4.2).
> 
> I'm not really a canonical HTTP expert, but I suspect that using GET to
> "subscribe" will raise some eyebrows at later stages of review. 

[Med] We are following RFC7641. I would be surprised if this is an issue. 

 Maybe
> we should just leave it as-is and wait for such review to arrive,
> though, rather than trying to do something preemptively.

[Med] Yes. 

> 
> I don't know if this is the proper section to talk about it, but we
> should probably have some text justifying the use of application-layer
> acknowledgment as opposed to just using Confirmable CoAP messages.

[Med] I'm not sure to understand this one. Which "application-layer acknowledgment" are you referring to?

> 
> Section 4.4.1
> 
> If Figure 5 is going to use actual/example values for cuid and mid, then
> I'd suggest also using actual/example values for the JSON fields
> (instead of "integer" and "string" and such).

[Med] I split the figure into two so that we don't have this problem. 

> 
>    cuid:  Stands for Client Unique Identifier.  A globally unique
>       identifier that is meant to prevent collisions among DOTS clients,
>       especially those from the same domain.  It MUST be generated by
>       DOTS clients.
> 
> In order to get global uniqueness we either need sufficient randomness
> or a hierarchical allocation strategy.  Since we recommend a strategy
> that involves hashing the (public) client certificate, we may also want
> to note that this value does not need to be unguessable.  If a random
> allocation is possible, I suggest giving guidance on how many random
> bits must be used to sufficiently ensure global uniqueness (128 might be
> enough).

[Med] An attack vector that can be achieved if the cuid is guessable is if a misbehaving client from within the client's domain succeeds to be granted access by the server and then uses the cuid of another client of the domain to delete active mitigation/etc.

For this attack vector to happen, the misbehaving client needs to pass security validation checks by the server. Therefore, I'm not sure if it is worth to add an allocation reco given this perquisite. 

Thoughts?

> 
>                           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.
> 
> side note: Truncation to 128 bits reduces the collision resistance to
> 64-bit strength, though this is probably acceptable in this use case.
> 
>       DOTS servers MUST return 4.09 (Conflict) error code to a DOTS peer
>       to notify that the 'cuid' is already in-use by another DOTS
>       client.  Upon receipt of that error code, a new 'cuid' MUST be
>       generated by the DOTS peer.
> 
> Is there any way in which this situation could arise during some sort of
> migration scenario?

[Med] This can be for example a client which does not follow the "SHOULD" for creating the cuid. 

> 
>       Client-domain DOTS gateways MUST handle 'cuid' collision directly
>       and it is RECOMMENDED that 'cuid' collision is handled directly by
>       server-domain DOTS gateways.
> 
> Is a gateway supposed to know if it is "client-side" or "server-side" by
> explicit configuration or some more automatic method?

[Med] This can be done by an explicit configuration. 

> 
>    'cuid' and 'mid' MUST NOT appear in the PUT request message body.
> 
> Do we need to say this given that there's no obvious structure in which
> to put them?  (That is, is this just a reminder to implementors of a
> previous version of the draft versus guidance to new implementations?)

[Med] We used to have those in the message body in previous versions of the spec/implementations. Furthermore, there are cases where "mid" is allowed to be included in the message body (e.g., PUT response). We included this note for implementers because of some behaviors observed during past interops.

> 
>       The prefix list MUST NOT include broadcast, loopback, or multicast
>       addresses.  These addresses are considered as invalid values.  In
> 
> Does "invalid" mean that the particular address gets ignored or that the
> entire request is rejected?

[Med] The expected behavior is covered by this text: 

" ... or contains invalid or unknown parameters, the DOTS server MUST reply with 4.00 (Bad Request)." 

> 
>    target-fqdn:   A list of Fully Qualified Domain Names (FQDNs)
>       identifying resources under attack.  An FQDN is the full name of a
>       resource, rather than just its hostname.  For example, "venera" is
>       a hostname, and "venera.isi.edu" is an FQDN [RFC1983].
> 
> I would suggest referring to draft-ietf-dnsop-terminology-bis rather
> than trying to reproduce a definition of FQDN.
> 

[Med] I added an informative reference to draft-ietf-dnsop-terminology-bis.
 
> We also may want to note that the DNS view can change depending on the
> vantage point used to make the observation.

[Med] Not sure what to do with this one given that the text says: 

"How a name is passed to an underlying name resolution library is implementation- and deployment-specific."

> 
> On page 18 we say that server-domain DOTS gateways "MUST supply [...]
> 'cdid'", but the previous paragraph says that there SHOULD be a
> configuration option for whether to insert 'cdid' on such systems.  The
> two requirements are in conflict; which was intended?  (I assume the
> MUST -- why would it be desired to not have the information available?)

[Med] This text is about gateways that are instructed to insert the cdid parameter. gateways facing a client's domain are in this case. 

I updated the text with "server-domain DOTS gateways instructed to insert the 'cdid' parameter MUST supply.."

> 
> The same paragraph also says that the 'cdid' is "likely to be the same
> as" the 'cuid', though in addition to the listed reasons the client only
> has a SHOULD requirement to follow this procedure for generating 'cuid';
> it may be worth noting the client's leeway here as well.

[Med] Yes, this is why we have "likely" in the text. 

> 
>       If a DOTS client is provisioned, for example, with distinct
>       certificates as a function of the peer server-domain DOTS gateway,
>       distinct 'cdid' values may be supplied by a server-domain DOTS
>       gateway.  The ultimate DOTS server MUST treat those 'cdid' values
>       as equivalent.
> 
> Is this paragraph trying to say that a client might supply different
> certs to different gateways in the same domain

[Med] Yes. 

 (e.g., if one such
> gateway does not support ecdsa certs)?  It was pretty confusing on the
> first read, in particular how the ultimate DOTS server would know that
> the different 'cdid' values actually correspond to the same client
> [domain].

[Med] This is supposed to be provisioned on the server. This is deployment-specific; hence no mention in the draft. 

> 
>       DOTS servers MUST ignore 'cdid' attributes that are directly
>       supplied by source DOTS clients or client-domain DOTS gateways.
>       This implies that first server-domain DOTS gateways MUST strip
>       'cdid' attributes supplied by DOTS clients.  DOTS servers SHOULD
>       support a configuration parameter to identify DOTS gateways that
>       are trusted to supply 'cdid' attributes.
> 
> Is there any mechanism (e.g., autodetection) other than this by which
> servers/proxies can learn about the topology information needed to
> fulfil these requirements?

[Med] I'm not aware of such mechanism. 

> 
>    Because of the complexity to handle partial failure cases, this
>    specification does not allow for including multiple mitigation
>    requests in the same PUT request.  Concretely, a DOTS client MUST NOT
>    include multiple 'scope' parameters in the same PUT request.
> 
> "multiple 'scope' parameters" reads like a CBOR object with duplicate
> keys; is this intended to refer to a multi-valued array?

[Med] What is intended is that the scope list should include only one entry. 

I can change to "multiple 'scope' clauses"

> 
>    The DOTS server couples the DOTS signal and data channel sessions
>    using the DOTS client identity and optionally the 'cdid' parameter
> 
> This requires the client to use the same certificate to authenticate the
> signal and data channels to a given server (even when a gateway is in
> use).  Above, we discussed cases where a client might have multiple
> certificates available.

[Med] Actually, the text above applies also if distinct certificates are used. Equivalent "client identity" are supposed to be known to the server by an out of band means. In all cases, the identity (same or equivalent) is used to couple the sessions. 

  Where do we specify the requirement to use the
> same certificate for signal and data channels?

[Med] We don't have such requirement in existing DOTS documents. 

> 
>                                                DOTS agents can safely
>    ignore Vendor-Specific parameters they don't understand.
> 
> This is not a very useful statemnet if the agent must know that a
> parameter is vendor-specific in order to safely ignore it.

[Med] The agent relies on the cbor key value to determine that a parameter can be safely ignored or not (comprehension-required). A range of keys is reserved for comprehension-optional. An agent checks the range to which belong a parameter, and then behaves accordingly. 

> 
>    If the DOTS server does not find the 'mid' parameter value conveyed
>    in the PUT request in its configuration data, it MAY accept the
>    mitigation request by sending back a 2.01 (Created) response to the
>    DOTS client; the DOTS server will consequently try to mitigate the
>    attack.
> 
>    If the DOTS server finds the 'mid' parameter value conveyed in the
>    PUT request in its configuration data bound to that DOTS client, it
>    MAY update the mitigation request, and a 2.04 (Changed) response is
>    returned to indicate a successful update of the mitigation request.
> 
> There are two "MAY"s spread across these two paragraphs; do we want to
> say anything about in what cases the server might want to have different
> behavior (i.e., ignore the MAY)?
> 

[Med] For the first MAY, a typical example is when a rate limit is enforced:

   Rate-limiting DOTS requests, including those with new 'cuid' values,
   from the same DOTS client defends against DoS attacks that would
   result in varying the 'cuid' to exhaust DOTS server resources.  Rate-
   limit policies SHOULD be enforced on DOTS gateways (if deployed) and
   DOTS servers

For the second MAY, the server may have more visibility on the attack and then may decide to update accordingly.

I don't know if it is worth to add examples. Any preference?