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 5:25 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)
> 
> 
> 
> 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."

Proposed update looks good, my response was to your reply "TLS false start may also be defined for DTLS" (I meant it's also applicable for DTLS :)).

Cheers,
-Tiru

> 
> > > * 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-informati
> > > > > ve-
> > > > > 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