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

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Konda, Tirumaleswar Reddy [mailto:[e-mail]]
> Envoyé : lundi 21 janvier 2019 10:13
> À : BOUCADAIR Mohamed TGI/OLN; Benjamin Kaduk
> Cc : [e-mail]; [e-mail]
> Objet : RE: [Dots] AD review of draft-ietf-dots-signal-channel-25 (5th Part)
> 
> > -----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).
> 

[Med] Not sure to get your comment. The initial point from Ben is valid, hence this addition to the draft: 

"TLS False Start is formally defined for use with TLS, but the same techniques are applicable to DTLS as well." 

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

[Med] Works for me. 

> 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