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

[Benjamin Kaduk <[e-mail]>]

Hi all,

Thanks for all the edits and the published -27.
Assuming I'm actually caught up on all the review/response threads, I think
we're pretty close to being able to go to IETF LC -- here's what I see as
still left:

- We need to settle the risk of needing normative downrefs called out for
  the last call
- I just noticed while reviewing the diff that we also need to say a
  little more about (D)TLS 1.3 0-RTT data (more below)
- It looks like we lost the guidance to the Experts and text about the
  review mailing list from the IANA Considerations, during the reshuffling
  around having IANA manage more things

Regarding the (D)TLS 1.3 0-RTT data, RFC 8446 notes that "Application
protocols MUST NOT use 0-RTT data without a profile that defines its use.
That profile needs to identify which messages or interactions are safe to
use with 0-RTT and how to handle the situation when the server rejects
0-RTT and falls back to 1-RTT."  So we either need to say which client
requests are 0-RTT safe (and why) or defer that profile to another
document.  draft-ietf-dnsop-session-signal is perhaps an example of a
document that specifies which messages are/aren't allowed in early data.
(draft-ietf-acme-acme is another, but an uninteresting one, since they make
every request include a single-use nonce, and all messages are 0-RTT safe.)
Our use of increasing 'mid' values may help here, in terms of allowing
DELETEs to be safe, but I'd have to think a little more to be sure that
requesting mitigation would be safe.  (On first glance the
session-managemnet bits would not be safe, but I may be missing something.)

Further notes inline.

On Thu, Jan 17, 2019 at 06:51:04AM +0000, [e-mail] wrote:
> 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?

Those documents' security considerations do seem to cover the relevant
points, yes.

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

It's a lower-case "recommended", which can probably eke by as descriptive
and not a "protocol feature" (see below).

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

It's a SHOULD ("SHOULD implement all of the following items"), though...

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

...per
https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/
note 1, "Even references that are relevant only for optional features must
be classified as normative if they meet the above conditions for normative
references."

This does seem to be something we actually need to care about before IETF
LC, though, as 7413 is Experimental and not listed in the downref registry
(https://datatracker.ietf.org/doc/downref/), so if we leave it as
Informational and have to change it later, we'd need to also restart/re-run
the IETF LC.

> , 7918
> [Med] Idem as TFO. 

This is Informational (i.e., also susceptible to the downref issue).

> , 7924
> [Med] Idem as TFO.  

(idem x2), though this is standards-track at least, so we have more leeway
to move things around later.



I think the most expedient thing to do here would just be to relax the
requirement for TLS Falst STart, TFO, and Cached Information, perhaps to
text like "The following items are additional mechanisms that can reduce
the delay required to deliver a DOTS signal channel message, which
implementations are encouraged to implement as possible.", but I am open to
other suggestions for what to do.


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

Agreed.

-Ben

> > should also be Normative.
> > 
> > 
> > -Ben
>