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 : Konda, Tirumaleswar Reddy [mailto:[e-mail]]
> Envoyé : jeudi 17 janvier 2019 07:54
> À : Benjamin Kaduk
> Cc : BOUCADAIR Mohamed TGI/OLN; [e-mail];
> [e-mail]
> Objet : RE: AD review of draft-ietf-dots-signal-channel-25 (2nd Part)
> 
> > -----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.

[Med] Yes. We can make this change if neeed:

s/until a response/until a CoAP response.


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

[Med] OK. 

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

[Med] OK.

> >
> > I don't think a UUID reference would be very valuable here.
> 
> If cuid collision happens, UUID can be used to generate the cuid.

[Med] Indeed. Text updated.

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

[Med] OK.

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

[Med] No problem.

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

[Med] I added this NEW text: 

      The use of FQDNs may be suboptimal because:

      *  It induces both an extra load and increased delays on the DOTS
         server to handle and manage DNS resolution requests.

      *  It does not guarantee that the DOTS server will resolve a name
         to the same IP 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.

[Med] Fixed. 

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

[Med] Fixed. 

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

[Med] Fixed. Thanks.