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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> Sent: Thursday, January 17, 2019 3:58 AM
> To: Konda, Tirumaleswar Reddy <[e-mail]>
> Cc: [e-mail]; draft-ietf-dots-signal-
> [e-mail]; [e-mail]
> Subject: Re: AD review of draft-ietf-dots-signal-channel-25 (2nd Part)
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> 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)?

No, the non-confirmable response is returned at the CoAP layer itself. 

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

Yup, will update Security Considerations.

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

If cuid collision happens, UUID can be used to generate the cuid. 

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

Yes, I too don't think a legitimate client will see this error code in the absence of an attack.

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

Good point, will update draft. 

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

Yes, proposed wording to say "MUST NOT include multiple entries in the 'scope' array" looks better. 

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

Nothing fancy, the two certificates will have the same distinguished name (DN) in the subject field. 
A CA can issue multiple certificates with the same DN to the DOTS client (or subject). 

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

Yes, will update.

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

Sure, will update draft.

Cheers,
-Tiru

> 
> -Ben