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

From: <[email-masked]>
Date: Thu, 17 Jan 2019 06:51:04 +0000

Hi Ben,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:[email-masked]]
> Envoyé : mercredi 16 janvier 2019 01:14
> À : [email-masked]
> Cc : [email-masked]
> 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?

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

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

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

, 7918
[Med] Idem as TFO. 

, 7924
[Med] Idem as TFO.  

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

> should also be Normative.
> 
> 
> -Ben

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 17 Jan 2019 10:33:38 +0000

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Thursday, January 17, 2019 12:21 PM
> To: Benjamin Kaduk <[email-masked]>; draft-ietf-dots-signal-
> [email-masked]
> Cc: [email-masked]
> 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 Ben,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > De : Benjamin Kaduk [mailto:[email-masked]] Envoyé : mercredi 16
> > janvier 2019 01:14 À : [email-masked]
> > Cc : [email-masked]
> > 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.

The DOTS signal channel draft is discussing PSK with (EC)DHE key establishment explained in RFC8446, and I don't see the need to refer to draft-housley-tls-tls13-cert-with-extern-psk-00. 
The 0-RTT diagram is a simplified version of 0-RTT just like the Figure 1 in https://tools.ietf.org/html/draft-ietf-quic-tls-17.

The only correction required to the diagram is end_of_early_data must be sent along with the client Finished message.

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

We should say "DTLS 1.2 overhead of 13 octets"
In DTLS 1.3 DTLSCiphertext structure is variable length (full header is of size 6 octets). 

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

I don't see "CBOR Map Keys" defined or used anywhere in the draft. 

> > registration should be directed to the mailing list or to IANA, as
> > we've had some confusion about this elsewhere.
> >
> > 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
> >
> > We need to specify which range of values we are asking for an
> > allocation from.
> 

As per https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml the allowed range is 23-255.

> > As above, specify what range we're asking about.

The range is already defined in section 9.6.1.1 

Cheers
-Tiru

> > IANA", so it would be good to have an answer ready even if we don't
> > put it in the document text.
> 
> > 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
> >
> > 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.
> 
> > 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.
> 
> > away with not citing RFC 3986.  On the other hand, it's not causing
> > any harm to leave it in...
> 
> [Med] Will leave it.
> 
> >
> [Med] This is a MAY in the spec. It is just fine to leave it as informative..
> 
> , 7918
> [Med] Idem as TFO.
> 
> , 7924
> [Med] Idem as TFO.
> 
> , and 7951
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: <[email-masked]>
Date: Thu, 17 Jan 2019 12:14:19 +0000

Re-,

Please see inline. 

Cheers,
Med

> De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
> Envoyé : jeudi 17 janvier 2019 11:34
> À : BOUCADAIR Mohamed TGI/OLN; Benjamin Kaduk; draft-ietf-dots-signal-
> [email-masked]
> Cc : [email-masked]
> Objet : RE: AD review of draft-ietf-dots-signal-channel-25 (5th Part)
> 
> The DOTS signal channel draft is discussing PSK with (EC)DHE key
> establishment explained in RFC8446, and I don't see the need to refer to
> draft-housley-tls-tls13-cert-with-extern-psk-00.
> The 0-RTT diagram is a simplified version of 0-RTT just like the Figure 1 in
> https://tools.ietf.org/html/draft-ietf-quic-tls-17.
> 

[Med] The proposal was to add it in -17. In my local copy I have implemented "CBOR Key Values". Better? 

> As per https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml the allowed

[Med] Ben was referring to 9.5.1 which is now 9.4.1 in -26. So the range I indicated is the correct one. 

> The range is already defined in section 9.6.1.1

[Med] Ben was referring to 9.6.1 of -25, which is now 9.5.1 in -26. The comment from Ben is a valid one. 

> > [Med] Would a pointer to the architecture/requirements I-Ds be sufficient
> to
> > cover to high-level aspects?
> >
> > >
> > > Section 13.1
> > >
> > [Med] Please refer to my answer to that question. draft-ietf-core-yang-cbor
> is
> > informative.
> >
> > >

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 17 Jan 2019 13:01:25 +0000

> From: [email-masked]
> <[email-masked]>
> Sent: Thursday, January 17, 2019 5:44 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> Benjamin Kaduk <[email-masked]>; [email-masked]
> Cc: [email-masked]
> Subject: RE: AD review of draft-ietf-dots-signal-channel-25 (5th Part)
> 
> 
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > De : Konda, Tirumaleswar Reddy
> > [mailto:[email-masked]]
> > [email-masked] Cc : [email-masked] Objet : RE: AD review of
> > draft-ietf-dots-signal-channel-25 (5th Part)
> >
> > > 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 Ben,
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > 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.
> >
> > establishment explained in RFC8446, and I don't see the need to refer
> > to draft-housley-tls-tls13-cert-with-extern-psk-00.
> > The 0-RTT diagram is a simplified version of 0-RTT just like the
> > Figure 1 in https://tools.ietf.org/html/draft-ietf-quic-tls-17.
> >
> > The only correction required to the diagram is end_of_early_data must
> > be sent along with the client Finished message.
> >
> > >
> > > > Section 7.3
> > > >
> > > > 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.
> > >
> > > >
> > > > 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.
> > > > If we don't want to use example.com vs. example.net as sample
> > > > domains, we can also use whateverwewant.example, per RFC 6761.
> > >
> > > > "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.
> > > >
> > >

Yes, thanks.

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

Got it.

> comment from Ben is a valid one.

Okay.

Thanks,
-Tiru

> 
> > Cheers
> > -Tiru
> >
> > >
> > > >
> > > > 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.
> > >
> > > > remember which ones it has seen in perpetuity, or can it time them
> > > > out eventually?
> > >
> > > 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.
> > >
> > > > I think the IANA registries should be listed as Informational and
> > > > not Normative references.
> > > >
> > >
> > > [Med] Done.
> > >
> > > > Section 13.2
> > > >
> > > > 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.
> > >
> > > >

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 18 Jan 2019 15:02:58 -0600

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.

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

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

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

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

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

> [Med] Idem as TFO. 

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

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

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

Agreed.

-Ben

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 19 Jan 2019 06:32:17 +0000

Hi Ben,

Please see inline

> From: Dots <[email-masked]> On Behalf Of Benjamin Kaduk
> Sent: Saturday, January 19, 2019 2:33 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> open attachments unless you recognize the sender and know the content is safe.
> 
> Hi all,
> 
> we're pretty close to being able to go to IETF LC -- here's what I see as still left:
> 
> 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.
> 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). 

> > > known to be authenticated when the server sends its initial
> > [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.
> >
> > >
> > > 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.
> >
> The DOTS server can set an interval in which the same client cannot present a
> new cuid.
> >
> > >
> > > Section 10
> > >
> > > requirements for and consequences of specific bits on the wire in
> > > the signal channel protocol.  I think it's appropriate to also
> Those documents' security considerations do seem to cover the relevant points,
> yes.
> 
> > >
> > > Section 13.1
> > >
> It's a lower-case "recommended", which can probably eke by as descriptive and
> not a "protocol feature" (see below).
> 
> > , 7413
> ....per
> 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.
> 
> (idem x2), though this is standards-track at least, so we have more leeway to
> move things around later.
> 
> 
> 
> 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

---

From: <[email-masked]>
Date: Mon, 21 Jan 2019 07:31:28 +0000

Hi Ben, all, 

Please see inline.

Cheers,
Med

> Envoyé : samedi 19 janvier 2019 07:32
> À : Benjamin Kaduk; BOUCADAIR Mohamed TGI/OLN
> Cc : [email-masked]; [email-masked]
> Objet : RE: [Dots] AD review of draft-ietf-dots-signal-channel-25 (5th Part)
> 
> Hi Ben,
> 
> Please see inline
> 

[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).
* tweak the TFO text to maintain it as informative. 

> >   around having IANA manage more things

[Med] That was on purpose. We would like to rely on RFC8126 rules for deigned expert reviews. 

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

> > > [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
> > > >
> a
> points,
> > > [Med] Please refer to my answer to that question. draft-ietf-core-yang-
> cbor is
> > informative.
> > >
> > > >
> be
> LC,
> Informational
> text
> 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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 21 Jan 2019 09:13:10 +0000

> From: [email-masked] <[email-masked]>
> Sent: Monday, January 21, 2019 1:01 PM
> Benjamin Kaduk <[email-masked]>
> Subject: RE: [Dots] AD review of draft-ietf-dots-signal-channel-25 (5th Part)
> 
> 
> 
> Hi Ben, all,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > À : Benjamin Kaduk; BOUCADAIR Mohamed TGI/OLN Cc :
> > [email-masked]; [email-masked] Objet : RE:
> > [Dots] AD review of draft-ietf-dots-signal-channel-25 (5th Part)
> >
> > Hi Ben,
> >
> > Please see inline
> >
> > > content is
> > > 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:
> > >

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] That was on purpose. We would like to rely on RFC8126 rules for

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.
> > > 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
> > > session-managemnet bits
> > would
> > 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.
> > (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).
> >
> 
> > > On Thu, Jan 17, 2019 at 06:51:04AM +0000,
> > > wrote:
> > > > >    (Section 4.1.1.1 of [RFC6347]).  If the request size exceeds
> > > > > the
> > path
> > > > gateway
> > > > >    messages from an authorized DOTS gateway, thereby creating a
> > > > > two-
> > link
> > > > >                  DOTS client certificate validation MUST be
> > > > > performed
> > as
> > > > > registration should be directed to the mailing list or to IANA,
> > > > > as we've had some confusion about this elsewhere.
> > > > >
> > > > > 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
> > > > >
> > > > > Do we want to say anything about the usage of negative integers
> > > > > as map keys?
> > > > >
> > > > > "maintained by IANA", so it would be good to have an answer
> > > > > ready even if we don't put it in the document text.
> > > >
> > > > > 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.
> > > present
> > > > > 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.
> > > >
> > > > > I think the IANA registries should be listed as Informational
> > > > > and not Normative references.
> > > > >
> > > >
> > > > [Med] Done.
> > > >
> > > > > Section 13.2
> > > > >
> > > > [Med] This one is not listed as normative because other hash algos
> > > > may be
> > > used.
> > >
> > > classified as normative if they meet the above conditions for
> > > normative references."
> > >
> > > 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
> > > 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
> > 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
> > >

---

From: <[email-masked]>
Date: Mon, 21 Jan 2019 11:55:11 +0000

Re-,

Please see inline.

Cheers,
Med

> Envoyé : lundi 21 janvier 2019 10:13
> À : BOUCADAIR Mohamed TGI/OLN; Benjamin Kaduk
> 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

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

> are idempotent requests. Further, CoAP (as discussed in Section 4.4 of
> RFC7252) is capable of performing message deduplication

[Med] Works for me.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 21 Jan 2019 14:19:14 +0000

> Sent: Monday, January 21, 2019 5:25 PM
> > À : BOUCADAIR Mohamed TGI/OLN; Benjamin Kaduk Cc :
> > > Subject: RE: [Dots] AD review of draft-ietf-dots-signal-channel-25
> > > (5th
> > Part)
> > >
> > >
> > >
> > > Hi Ben, all,
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > Envoyé : samedi 19 janvier 2019 07:32 À : Benjamin Kaduk;
> > > > BOUCADAIR Mohamed TGI/OLN Cc :
> > > > > Subject: Re: [Dots] AD review of
> > > > > This email originated from outside of the organization. Do not
> > > > > click links
> > > > or
> > > > > 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
> > >
> > > * 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

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

> > RFC7252) is capable of performing message deduplication to handle
> > replay of CoAP requests.
> >
> 
> [Med] Works for me.
> 
> > Cheers,
> > -Tiru
> >
> > >
> > > > > with 0-RTT and how to handle the situation when the server
> > > > > rejects 0-RTT
> > > > and
> > > > > 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
> > > > 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
> > > > [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).
> > > >
> > >
> > > > > > > De : Benjamin Kaduk [mailto:[email-masked]] Envoyé : mercredi
> > > > > > > 16 janvier 2019 01:14 À :
> > > > > > > [email-masked]
> > > > > > > Cc : [email-masked]
> > > > > > > Additionally, the usage of PSK as well as a certificate is
> > > > > > > not defined until
> > > > > > > I also note that in the diagram as presented, the client is
> > > > > > > not yet known to be authenticated when the server sends its
> > > > > > > initial
> > > > > > > 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.
> > > > > >
> > > > > > >                               Path MTU MUST be greater than
> > > > > > > or
> > equal to
> > > > > > >    (Section 4.1.1.1 of [RFC6347]).  If the request size
> > > > > > > exceeds the
> > > > path
> > > > > > >    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.
> > > > > > >
> > > > > > > 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?
> > > > > >
> > > > > > >    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.
> > > > > >
> > > > > > >    per [RFC5280] and the DOTS client certificate MUST
> > > > > > > conform to
> > the
> > > > > > > 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.
> > > > > >
> > > > > > > "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.
> > > > > > >
> > > > > >
> > > > > > > registration should be directed to the mailing list or to
> > > > > > > IANA, as we've had some confusion about this elsewhere.
> > > > > > >
> > > > > > > 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
> > > > > > >
> > > > > > > Do we want to say anything about the usage of negative
> > > > > > > integers as map keys?
> > > > > > >
> > > > > > > We need to specify which range of values we are asking for
> > > > > > > an allocation from.
> > > > > >
> > > > > > > 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 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.
> > > > > >
> > > > > > > I think the IANA registries should be listed as
> > > > > > > Informational and not Normative references.
> > > > > > >
> > > > > >
> > > > > > [Med] Done.
> > > > > >
> > > > > > > Section 13.2
> > > > > > >
> > > > > > > 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.
> > > > > >
> > > > > > >
> > > > > > [Med] This one is not listed as normative because other hash
> > > > > > algos may be
> > > > > used.
> > > > >
> > > > > > [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/
> > > > > 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.
> > > > >
> > > > > 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
> > > > 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:
> > > > 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
> > > > >

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 21 Jan 2019 09:06:57 -0600

> to handle replay of CoAP requests.

RFC 8126 is "guidelines for writing an IANA considerations section", a
separate topic from TLS 1.3 O-RTT anti-replay.

I'll try to take a closer look at what the CoAP deduplication provides.
However, I'll note that mere idempotence is not always sufficient to
alleviate replay concerns for 0-RTT data, as we must also consider the
possibilities of reordering with other messages and other side effects.
For example, the GET we use to establish a subscription to server status
messages -- the subscription is a side effect not related directly to the
GET exchange.

In any case, even if we do conclude that we are sufficiently protected, we
still need an explicit statement like "due to the protections afforded by
CoAP deduplication and RFC 8446 anti-replay mechanisms, all DOTS signal
channel messages are safe to transmit in TLS 1.3 0-RTT data".

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 21 Jan 2019 09:10:25 -0600

> * tweak the TFO text to maintain it as informative. 

Sounds good.

> [Med] That was on purpose. We would like to rely on RFC8126 rules for deigned expert reviews. 

I'm not sure I understand this -- 8126 explicitly says that documents
should provide guidance to the designated expert on what to look for and
what is grounds for rejecting a request.

>       A DOTS server can reject 0-RTT by sending a TLS HelloRetryRequest.

(As I noted in my reply to Tiru, we need a more explicit statement.)

-Ben

---

From: <[email-masked]>
Date: Mon, 21 Jan 2019 15:37:38 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : lundi 21 janvier 2019 16:10
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Konda, Tirumaleswar Reddy; [email-masked];
> [email-masked]
> Objet : Re: [Dots] AD review of draft-ietf-dots-signal-channel-25 (5th Part)
> 

[Med] What I meant is that the text we used to have in -25 is generic, and IMHO does not bring new guidelines to what is discussed in Section 5 of 8126. 

> > > > 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
> requesting
> handle

[Med] OK. If the assessment is confirmed, we can update the text as follows:  

      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.
      The DOTS signal channel messages sent as early data by the DOTS
      client are idempotent requests.  Owing to the protections afforded
      by CoAP deduplication (Section 4.5 of [RFC7252]) and RFC 8446
      anti-replay mechanisms, all DOTS signal channel messages are safe
      to transmit in TLS 1.3 0-RTT data.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 21 Jan 2019 12:10:33 -0600

> [Med] What I meant is that the text we used to have in -25 is generic, and IMHO does not bring new guidelines to what is discussed in Section 5 of 8126. 

I think there can still be value in repeating the "general applicability,
clarity of description, etc. language.  (But it would be even better to
come up with some guidance that is tightly tailored to DOTS, if we can.)
And the text about the mailing list and how to format registration requests
is definitely not covered in 8126!

>       to transmit in TLS 1.3 0-RTT data.

That text would meet the "application profile" requirements.  Hopefully
it's a true statement so we can actually use it :)

-Ben

---

From: <[email-masked]>
Date: Tue, 22 Jan 2019 07:15:37 +0000

Hi Ben, 

Please see inline.

Cheers,
Med

> Envoyé : lundi 21 janvier 2019 19:11
> > > > > Objet : RE: [Dots] AD review of draft-ietf-dots-signal-channel-25
> (5th
> > > Part)
> > > > >
> > > > > Hi Ben,
> > > > >
> > > > > Please see inline
> > > > >
> click
> content
> 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
> > > >
> > > > * cite 7618/7624 as normative (+ indicate that a similar mechanism to
> false
> > > start may also be defined for DTLS).
> > [Med] What I meant is that the text we used to have in -25 is generic, and
> IMHO does not bring new guidelines to what is discussed in Section 5 of 8126.
> 

[Med] I tried, actually. It is indeed when I rechecked 8126 that I found that text is generic. Seeking for expert reviews will be done via IANA, which is familiar with the process of soliciting experts. 

Moreover, I found a bug in the text because it does not apply to the range requiring IETF review, but only to a the comprehensive-optional range. 

> is definitely not covered in 8126!

[Med] that mailing list is likely to include the designed experts. This is why I thought it is simple to let IANA decide how to reach out designed expert(s) once assigned. 

Anyway, I can reinsert the text if you still think it brings value. 

> "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
> 0-
> requests
> > > > > > safe (and why) or defer that profile to another document.  draft-
> ietf-
> > > > > dnsop-
> which
> they
> > > make
> > > > > > every request include a single-use nonce, and all messages are 0-
> RTT
> > > safe.)
> > > > > > mitigation would be safe.  (On first glance the session-managemnet
> bits
> > > > > would
> CoAP
> does
> > > not

[Med] That is at least the authors' conclusion :) 
We will wait for your ACK before implementing changes and posting the updated version of the draft.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 22 Jan 2019 10:08:00 +0000

> Sent: Tuesday, January 22, 2019 12:46 PM
> To: Benjamin Kaduk <[email-masked]>
> Cc: Konda, Tirumaleswar Reddy <[email-masked]>;
> [email-masked]; [email-masked]
> > De : Benjamin Kaduk [mailto:[email-masked]] Envoyé : lundi 21 janvier
> > 2019 19:11 À : BOUCADAIR Mohamed TGI/OLN Cc : Konda, Tirumaleswar
> > Reddy; [email-masked];
> > [email-masked]
> > > > De : Benjamin Kaduk [mailto:[email-masked]] Envoyé : lundi 21
> > > > janvier 2019 16:10 À : BOUCADAIR Mohamed TGI/OLN Cc : Konda,
> > > > Tirumaleswar Reddy; [email-masked];
> > > > [email-masked]
> > > > Objet : Re: [Dots] AD review of draft-ietf-dots-signal-channel-25
> > > > (5th
> > Part)
> > > >
> > > > On Mon, Jan 21, 2019 at 07:31:28AM +0000,
> > > > > > [email-masked]; [email-masked] Objet :
> > > > > > RE: [Dots] AD review of draft-ietf-dots-signal-channel-25
> > (5th
> > > > Part)
> > > > > >
> > > > > > Hi Ben,
> > > > > >
> > > > > > Please see inline
> > > > > >
> > > > > > > draft-ietf-dots-signal-channel-25
> > (5th
> > > > > > Part)
> > > > > > >
> > > > > > > threads,
> > > > > > > called
> > > > > > > - I just noticed while reviewing the diff that we also need
> > > > > > > to say
> > a
> > > > > > > - It looks like we lost the guidance to the Experts and text
> > > > > > > about
> > the
> > > > > > >   review mailing list from the IANA Considerations, during
> > > > > > > the
> > > > reshuffling
> > > > > [Med] That was on purpose. We would like to rely on RFC8126
> > > > > rules for
> > > > deigned expert reviews.
> > > >
> > > > I'm not sure I understand this -- 8126 explicitly says that
> > > > documents should provide guidance to the designated expert on what
> > > > to look for and what is grounds for rejecting a request.
> > > >
> > >
> > I think there can still be value in repeating the "general
> > applicability, clarity of description, etc. language.  (But it would
> > be even better to come up with some guidance that is tightly tailored
> > to DOTS, if we can.)
> 
> [Med] I tried, actually. It is indeed when I rechecked 8126 that I found that text
> is generic. Seeking for expert reviews will be done via IANA, which is familiar
> with the process of soliciting experts.
> 
> Moreover, I found a bug in the text because it does not apply to the range
> requiring IETF review, but only to a the comprehensive-optional range.
> 
> > And the text about the mailing list and how to format registration
> > requests is definitely not covered in 8126!
> 
> [Med] that mailing list is likely to include the designed experts. This is why I
> thought it is simple to let IANA decide how to reach out designed expert(s) once
> assigned.
> 
> > > > > > > rejects
> > > > > > > draft-
> > > > > > > specifies
> > > > > > > since
> > > > > > > Our use of increasing 'mid' values may help here, in terms
> > > > > > > of
> > allowing
> > > > > > DELETEs
> > > > > > confirmable
> > > > > > suffice
> > > > > > anti-replay (e.g. an attacker replaying a 0-RTT data carrying
> > That text would meet the "application profile" requirements.
> > Hopefully it's a true statement so we can actually use it :)
> >
> 
> [Med] That is at least the authors' conclusion :) We will wait for your ACK
> before implementing changes and posting the updated version of the draft.

We can add the following lines to strengthen our statements:

Message ID (Section 3 of RFC7252) is changed each time a new CoAP request is sent, and the token (Section 5.3.1 of RFC7252) in each
CoAP request is randomized. DOTS server system can use Message ID and token in the DOTS signal message to detect replay of early data, 
and accept 0-RTT data at most once.
Further, 'mid' value is monotonically increased by the DOTS client for each mitigation request, attackers replaying mitigation request 
with lower numeric 'mid' value and over-lapping scope with mitigation requests with higher numeric 'mid' values
will be rejected by the DOTS server.

Cheers
-Tiru