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

[Benjamin Kaduk <[e-mail]>]

On Wed, Jan 16, 2019 at 01:30:01PM +0000, Konda, Tirumaleswar Reddy wrote:
> > -----Original Message-----
> > From: Dots <[e-mail]> On Behalf Of
> > [e-mail]
> > Sent: Wednesday, January 16, 2019 4:11 PM
> > To: Benjamin Kaduk <[e-mail]>; draft-ietf-dots-signal-
> > [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [Dots] AD review of draft-ietf-dots-signal-channel-25 (2nd Part)
> > 
> > 
> > 
> > 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.

Sounds good.

> > >
> > > 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?

Maybe I was just misreading.  Does

   Requests marked by the DOTS client as Non-confirmable messages are
   sent at regular intervals until a response is received from the DOTS
   server.

refer to a "response" at the application layer (as opposed to the CoAP
layer)?

> > >
> > > 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?

I don't think we need to have text around 'cuid' allocation, but should
mention the possibility of this spoofing attack by a compromised client, in
the security considerations.

> UUID discussed in https://tools.ietf.org/html/rfc4122 is another way of generating a globally unique identifier.  A compromised DOTS client 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 with TLS 1.3 (TLS handshake is encrypted).

For 1.3 the attacker would need to have data from a server in order to see
another client's certificate, yes, which is presumably a harder attack.

I don't think a UUID reference would be very valuable here.

> Cheers,
> -Tiru
> 
> > 
> > >
> > >                           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.

Of course.  I'm wondering if a legitmiate client that does follow the
"SHOULD" could ever see this error code in the absence of an attack, for
example if the client's network address changes.

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

Okay.  Let's wait to see if any other reviewers ask for clarifying text
that this can only be known via 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.

Okay.  (I think this is actually one of the things I asked before and you
already answered; sorry for the duplication.)

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

Thanks

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

I was thinking something like "the results returned for resolving a name
can depend on many factors, including when the request was made and the
address of the DNS resolver used -- there is no guarantee that the DOTS
server will resolve a name to the same addresses that the DOTS client
does".

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

Ah, that makes sense -- thanks.

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

Ah, thanks for the explanation.  I don't have any suggested rewording that
would help clarify -- all I can come up with is to add ", when configured
to know they represent the same client", which is both long and not really
saying anything new.

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

Okay, thanks.

> > >
> > >    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"

I'm not sure how different that is.  It sounds like you're trying to avoid
"multiple entries in the 'scope' array"?

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

Hmm.  If we are talking anything fancier than just comparing Subject
information from the certificate (which apparently I forgot about when I
wrote the above!), I think we may want to have some text in the document
mentioning the possibility of out of band configuration.

> >   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 we really mean comprehension-optional, maybe we should just say that,
instead of "Vendor-Specific".

> > >
> > >    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?

I would lean towards adding "A server could reject mitigation requests when
it is near capacity or needs to rate-limit a particular client, for
example" for the former, but leaving the latter as-is.  But I have no
strong preferences here and am happy to advance the document either way.

-Ben