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

[<[e-mail]>]

Hi Ben,

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 7.2
> 
> The TLS 1.3 handshake with 0-RTT diagram needs to be
> revisited/refreshed, as RFC 8446 does not look like that.  Additionally,
> the usage of PSK as well as a certificate is not defined until
> draft-housley-tls-tls13-cert-with-extern-psk is published.
> I also note that in the diagram as presented, the client is not yet
> known to be authenticated when the server sends its initial (0.5-RTT)
> DOTS signal message.
> 

[Med] Noted. Thanks.

> Section 7.3
> 
> This whole section seems to only be relevant for UDP usage, so probably
> the "If UDP is used" clause can be dropped and an introductory statement
> added earlier on.

[Med] Will consider that. 

> 
>                               Path MTU MUST be greater than or equal to
>    [CoAP message size + DTLS overhead of 13 octets + authentication
>    overhead of the negotiated DTLS cipher suite + block padding]
>    (Section 4.1.1.1 of [RFC6347]).  If the request size exceeds the path
>    MTU then the DOTS client MUST split the DOTS signal into separate
>    messages, for example the list of addresses in the 'target-prefix'
>    parameter could be split into multiple lists and each list conveyed
>    in a new PUT request.
> 
> (DTLS 1.3 will have a short header for some packets, that is less than
> 13 octets.)

[Med] The text is more about 1.2. We can add a 1.3 note if you think it is useful for the discussion. 

> 
> Section 8
> 
> We've got some requirements in here about limiting behavior of
> clients/servers when talking to gateways; is knowing about the presence
> of a gateway something that's required to happen out of band or is there
> an in-band way to identify that the peer is a gateway?

[Med] An agent does not necessary know that it peer is gateway. A gateway is seen as a server for the client, and a client for a server. 

> 
>    messages from an authorized DOTS gateway, thereby creating a two-link
>    chain of transitive authentication between the DOTS client and the
>    DOTS server.
> 
> This seems to ignore the possibility of setups that include both
> client-domain and server-domain gateways.

[Med] I updated the text to mention this is only an example. 

> 
>                  DOTS client certificate validation MUST be performed as
>    per [RFC5280] and the DOTS client certificate MUST conform to the
>    [RFC5280] certificate profile.  [...]
> 
> This seems to duplicate a requirement already stated in Section 7.1;
> it's probably best to only have normative language in one location, even
> if we need to mention the topic in multiple locations.
> Similarly for the mutual authentication requirement, which we duplicate
> in the second and fourth paragraphs of this section.

[Med] Good point. Fixed. 

> 
> If we don't want to use example.com vs. example.net as sample domains,
> we can also use whateverwewant.example, per RFC 6761.

[Med] Will maintain the ones already in the draft. Thanks. 

> 
> Section 9
> 
> We should mention the media-type allocation in the top-level section.

[Med] Will fix that.  

> 
> "mappings to CBOR" feels confusing to me, since it leaves empty what we
> are mapping from.  Perhaps just talking about a registry of "CBOR map
> keys" would be better, both here and in the Section 9.3 intro.
> 

[Med] Unless there is an objection, I can use "CBOR Map Keys".

> Section 9.3
> 
> I suggest being very explicit about whether new requests for
> registration should be directed to the mailing list or to IANA, as we've
> had some confusion about this elsewhere.
> 
> The criteria used by the experts also just lists things they should
> consider, but does not provide full clarity on which answer to the
> question is more likely to be approved.  (And yes, I know that this text
> is largely copied from already published RFCs, but we can still do
> better.)

[Med] Will check this. 

> 
> Section 9.3.1
> 
> If we want the value 0 to be reserved we need to say so.

[Med] 0 is not part of the allocation range. 

> Do we want to say anything about the usage of negative integers as map
> keys?
> 
> I suggest not mentioning the postal address, given the recent (e.g.)
> GDPR requirements.

[Med] Good point. Done. 

> 
> Section 9.3.2
> 
> It may be worth mentioning Table 4 here as well.

[Med] OK. 

> 
> Section 9.5.1
> 
> We need to specify which range of values we are asking for an allocation
> from.

[Med] Added a mention to 0-255 range. 

> 
> Section 9.6.1
> 
> As above, specify what range we're asking about.

[Med] OK.

> 
> I expect the current text to get some IESG (or directorate) feedback
> that the Data Item and Semantics descriptions are repetitive and banal.
> 
> Section 9.7
> 
> IIUC, IANA is going to ask if we want this module to be "maintained by
> IANA", so it would be good to have an answer ready even if we don't put
> it in the document text.

[Med] This is discussed in -26.

> 
>    Rate-limiting DOTS requests, including those with new 'cuid' values,
>    from the same DOTS client defends against DoS attacks that would
> 
> With respect to "new" 'cuid' values, is the server required to remember
> which ones it has seen in perpetuity, or can it time them out
> eventually?

[Med] The attack vector is a DOTS client which changes frequently its cuid. The DOTS server can set an interval in which the same client cannot present a new cuid.

> 
> Section 10
> 
> The security considerations seem to be taking a narrow focus on the
> requirements for and consequences of specific bits on the wire in the
> signal channel protocol.  I think it's appropriate to also include some
> high-level thoughts about the functional behavior of the protocol,
> allowing to signal that an attack is underway and trigger mitigation,
> increasing the availability of services, etc., and the risks that are
> posed by the protocol failing to work properly, whether that means
> letting attack traffic through or improperly blocking legitimate
> traffic.

[Med] Would a pointer to the architecture/requirements I-Ds be sufficient to cover to high-level aspects?

> 
> Section 13.1
> 
> I think the IANA registries should be listed as Informational and not
> Normative references.
> 

[Med] Done. 

> Section 13.2
> 
> Pending resolution of the question about using draft-ietf-core-yang-cbor
> rules or RFC7951+RFC7049, the draft-ietf-core-yang-cbor reference may
> need to be Normative.

[Med] Please refer to my answer to that question. draft-ietf-core-yang-cbor is informative. 

> 
> Given that "URI" is a well-known abbreviation, we may be able to get
> away with not citing RFC 3986.  On the other hand, it's not causing any
> harm to leave it in...

[Med] Will leave it. 

> 
> RFC 4632 needs to be Normative, since we need to know CIDR to
> encode/decode target-prefixes.

[Med] Works for me. 

> 
> Similarly, I think that RFCs 6234

[Med] This one is not listed as normative because other hash algos may be used. 

, 7413
[Med] The support if TFO is not mandatory.  

, 7589
[Med] This is a MAY in the spec. It is just fine to leave it as informative. 

, 7918
[Med] Idem as TFO. 

, 7924
[Med] Idem as TFO.  

, and 7951
[Med] this one was not listed as normative because the document lists two ways to do the mapping.  

> should also be Normative.
> 
> 
> -Ben