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

From: <[email-masked]>
Date: Wed, 16 Jan 2019 10:41:14 +0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:[email-masked]]
> Envoyé : mercredi 16 janvier 2019 01:14
> À : [email-masked]
> Cc : [email-masked]
> 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?

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 16 Jan 2019 13:30:01 +0000

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Wednesday, January 16, 2019 4:11 PM
> To: Benjamin Kaduk <[email-masked]>; draft-ietf-dots-signal-
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [Dots] AD review of draft-ietf-dots-signal-channel-25 (2nd Part)
> 
> 
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > De : Benjamin Kaduk [mailto:[email-masked]] Envoyé : mercredi 16
> > janvier 2019 01:14 À : [email-masked]
> > Cc : [email-masked]
> > 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.
> 
> > 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
> > 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?

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

Cheers,
-Tiru

> > Is there any way in which this situation could arise during some sort
> > of migration scenario?
> 
> > Is a gateway supposed to know if it is "client-side" or "server-side"
> > by explicit configuration or some more automatic method?
> 
> > 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.
> 
> >
> > Does "invalid" mean that the particular address gets ignored or that
> > the entire request is rejected?
> 
> "How a name is passed to an underlying name resolution library is
> implementation- and deployment-specific."
> 
> >
> > 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.
> 
> > 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] What is intended is that the scope list should include only one entry..
> 
> > 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.
> 
> [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.
> 
> >
> > say anything about in what cases the server might want to have
> > different behavior (i.e., ignore the MAY)?
> >
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 16 Jan 2019 16:27:41 -0600

> > > though, rather than trying to do something preemptively.

Sounds good.

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

> > to add an allocation reco given this perquisite.

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 certifica…

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.

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

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.

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

> > included this note for implementers because of some behaviors observed

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

> > [Med] I added an informative reference to draft-ietf-dnsop-terminology-bis.

Thanks

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

> > the 'cdid' parameter MUST supply.."

Ah, that makes sense -- thanks.

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

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

Okay, thanks.

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

> > out of band means. In all cases, the identity (same or equivalent) is used to

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.

> > belong a parameter, and then behaves accordingly.

If we really mean comprehension-optional, maybe we should just say that,
instead of "Vendor-Specific".

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 17 Jan 2019 06:54:02 +0000

> From: Benjamin Kaduk <[email-masked]>
> Sent: Thursday, January 17, 2019 3:58 AM
> To: Konda, Tirumaleswar Reddy <[email-masked]>
> Cc: [email-masked]; draft-ietf-dots-signal-
> [email-masked]; [email-masked]
> 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.
> 
> > > > 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.
> > >
> > > > 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.
> > >
> 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).
> > >
> > > > 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?
> 
> > 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).
> 

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. 

> > > > side note: Truncation to 128 bits reduces the collision resistance
> > > > to 64-bit strength, though this is probably acceptable in this use case.
> > > >
> > > > 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.
> 

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

> Okay.  Let's wait to see if any other reviewers ask for clarifying text that this
> can only be known via explicit configuration.
> 
> > > >
> > > > 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.
> 
> > > > Does "invalid" mean that the particular address gets ignored or
> > > > that the entire request is rejected?
> > >
> > > > I would suggest referring to draft-ietf-dnsop-terminology-bis
> > > > rather than trying to reproduce a definition of FQDN.
> > > >
> > >
> > > > We also may want to note that the DNS view can change depending on
> > > > the vantage point used to make the observation.
> > >
> 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
> 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.."
> 
> > > > 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.
> > >
> > > > 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.
> 
> 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.
> 
> > > >
> > > > 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?
> > >
> > > > "multiple 'scope' parameters" reads like a CBOR object with
> > > > duplicate keys; is this intended to refer to a multi-valued array?
> > >

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

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

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

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

Yes, will update.

> > > > 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)?
> > > >
> > >
> > > For the second MAY, the server may have more visibility on the
> > > attack and then may decide to update accordingly.
> > >
> 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

---

From: <[email-masked]>
Date: Thu, 17 Jan 2019 08:17:39 +0000

Re-,

Please see inline. 

Cheers,
Med

> De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
> Envoyé : jeudi 17 janvier 2019 07:54
> À : Benjamin Kaduk
> Cc : BOUCADAIR Mohamed TGI/OLN; [email-masked];
> [email-masked]
> Objet : RE: AD review of draft-ietf-dots-signal-channel-25 (2nd Part)
> 

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

s/until a response/until a CoAP response.

> > the security considerations.

[Med] OK. 

> Yup, will update Security Considerations.

[Med] OK.

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

[Med] Indeed. Text updated.

> that this

[Med] OK.

> > already answered; sorry for the duplication.)

[Med] No problem.

> can

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

> to

[Med] Fixed. 

> > instead of "Vendor-Specific".

[Med] Fixed. 

> example" for

[Med] Fixed. Thanks.