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

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

Hi Ben,

Please see inline

> -----Original Message-----
> From: Dots <[e-mail]> On Behalf Of Benjamin Kaduk
> Sent: Saturday, January 19, 2019 2:33 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [Dots] AD review of draft-ietf-dots-signal-channel-25 (5th 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.
> 
> 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.)

The draft only uses idempotent requests (GET, PUT and DELETE), and CoAP is capable of detecting message duplication (see https://tools.ietf.org/html/rfc7252#section-4.5) for both confirmable and non-confirmable messages.  
 [1] An attacker replaying DELETE will not have any adverse impact, 2.02 (Deleted) Response Code is returned even if the mitigation request does not exist.
[2] The techniques discussed in Section 8 of RFC8446 should suffice to handle anti-replay (e.g. an attacker replaying a 0-RTT data carrying an old mitigation request replaced by a new mitigation scope). 

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

TLS False Start and Cached Information can be made normative references (just like we referenced these items in our spec https://tools.ietf.org/html/rfc8310)
TFO is for TCP only and that too for exception scenarios where UDP is blocked. TFO can removed from the list of items the DOTS agents SHOULD implement.

NEW:
Compared to UDP, DOTS signal channel over TCP requires an additional round-trip time (RTT) of latency to establish a TCP connection.  Implementations are encouraged to implement TCP
Fast Open [RFC7413] to eliminate that RTT when information exists from prior TCP connection. 

-Tiru

> 
> 
> > , 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
> >
> 
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots