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

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

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Monday, January 21, 2019 1:01 PM
> To: Konda, Tirumaleswar Reddy <[e-mail]>;
> Benjamin Kaduk <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: RE: [Dots] AD review of draft-ietf-dots-signal-channel-25 (5th Part)
> 
> 
> 
> Hi Ben, all,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Konda, Tirumaleswar Reddy
> > [mailto:[e-mail]]
> > Envoyé : samedi 19 janvier 2019 07:32
> > À : Benjamin Kaduk; BOUCADAIR Mohamed TGI/OLN Cc :
> > [e-mail]; [e-mail] Objet : RE:
> > [Dots] AD review of draft-ietf-dots-signal-channel-25 (5th Part)
> >
> > 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
> 
> [Med] I updated the text to:
> * cite 7618/7624 as normative (+ indicate that a similar mechanism to false
> start may also be defined for DTLS).

https://tools.ietf.org/html/rfc7918 does not require any changes to (D)TLS on-the-wire protocol data, and DLTS also supports false start (see the (D)TLS profile for IoT devices specified in 
https://tools.ietf.org/html/rfc7925#section-21).

> * tweak the TFO text to maintain it as informative.
> 
> > > - 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
> > >
> 
> [Med] That was on purpose. We would like to rely on RFC8126 rules for
> deigned expert reviews.

In addition to RFC8126 to defend against replay attacks, we can add the following additional rules:

The DOTS signal channel messages sent as early data by the DOTS client
are idempotent requests. Further, CoAP (as discussed in Section 4.4 of RFC7252) is capable of performing message deduplication
to handle replay of CoAP requests.

Cheers,
-Tiru

> 
> > > 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).
> >
> 
> [Med] FWIW, we do already have this text in the draft:
> 
>       Section 8 of [RFC8446] discusses some mechanisms to implement to
>       limit the impact of replay attacks on 0-RTT data.  If the DOTS
>       server accepts 0-RTT, it MUST implement one of these mechanisms.
>       A DOTS server can reject 0-RTT by sending a TLS HelloRetryRequest.
> 
> > >
> > > 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