Subject: Re: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-signal-channel)

From: <[email-masked]>
Date: Fri, 15 Feb 2019 15:01:29 +0000

Hi Ben,

What is the status for this one? Are we OK to move forward? 

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]]
> Envoyé : mardi 29 janvier 2019 14:32
> À : Benjamin Kaduk
> Cc : Konda, Tirumaleswar Reddy; [email-masked];
> [email-masked]
> Objet : Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf-dots-
> signal-channel)
> 
> Hi Ben, all,
> 
> We edited a short draft (https://tools.ietf.org/html/draft-boucadair-dots-
> earlydata-00) to motivate the following text included in the signal channel
> 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.
>       The DOTS signal channel messages sent as early data by the DOTS
>       client are idempotent requests.  As a reminder, 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]) is randomized
>       in each CoAP request.  The DOTS server(s) can use Message ID and
>       Token in the DOTS signal channel message to detect replay of early
>       data, and accept 0-RTT data at most once.  Furthermore, 'mid'
>       value is monotonically increased by the DOTS client for each
>       mitigation request, attackers replaying mitigation requests with
>       lower numeric 'mid' values and overlapping scopes with mitigation
>       requests having higher numeric 'mid' values will be rejected
>       systematically by the DOTS server.
> 
>       Owing to the aforementioned protections, especially those afforded
>       by CoAP deduplication (Section 4.5 of [RFC7252]) and RFC 8446
>       anti-replay mechanisms, all DOTS signal channel requests are safe
>       to transmit in TLS 1.3 as early data.  Refer to
>       [I-D.boucadair-dots-earlydata] for more details.
> 
> This text and also the Designated Expert guidelines are implemented in -28.
> These are the two pending issues from your AD review.
> 
> Other edits were also made to record what was agreed on the list.
> 
> We hope this version is now ready to move forward.
> 
> Cheers,
> Med
> 
> > > > > > 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 15 Feb 2019 09:04:58 -0600

Hi Med,

Short form: I need to think about it harder.  There's some indication that
the CoAp Message ID is at the wrong level to protect the 0-RTT data, but
I'm not sure yet.

Sorry for the delays; this has been a frenetic couple weeks :(

-Ben

---

From: <[email-masked]>
Date: Fri, 15 Feb 2019 15:36:05 +0000

Re-,

Looking forward to discuss this further. 

I wonder whether you can consider putting the document in the IETF LC for now. If it happen that we need to modify the 0-RTT text, we will handle it as other IETF LC comments.

Cheers,
Med

> De : Benjamin Kaduk [mailto:[email-masked]]
> Envoyé : vendredi 15 février 2019 16:05
> À : BOUCADAIR Mohamed TGI/OLN
> Objet : Re: Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf-
> dots-signal-channel)
> 
> Hi Med,
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 16 Feb 2019 08:11:02 +0000

> -----Original Message-----
> From: Benjamin Kaduk <[email-masked]>
> Sent: Friday, February 15, 2019 8:35 PM
> To: [email-masked]
> Cc: Konda, Tirumaleswar Reddy <[email-masked]>;
> [email-masked]; [email-masked]
> Subject: Re: Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf-dots-
> signal-channel)
> 
> 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 Med,
> 
> Short form: I need to think about it harder.  There's some indication that the
> CoAp Message ID is at the wrong level to protect the 0-RTT data, but I'm not
> sure yet.

I don't think Message ID and Token are at a wrong level to protect 0-RTT data, https://tools.ietf.org/html/draft-tschofenig-uta-tls13-profile-01 discusses introducing a new CoAP option "timestamp", which allows the client to attach a timestamp to each CoAP message for the purpose 
of replay detection. 

Cheers,
-Tiru

> > > Envoyé : mardi 29 janvier 2019 14:32 À : Benjamin Kaduk Cc : Konda,
> > > Tirumaleswar Reddy; [email-masked];
> > > [email-masked]
> > > We edited a short draft
> > > (https://tools.ietf.org/html/draft-boucadair-dots-
> > > > > > > anti-replay (e.g. an attacker replaying a 0-RTT data
> > > > > > > carrying an old mitigation request replaced by a new mitigation
> scope).
> > > > > > >
> > > > > >

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 18 Feb 2019 10:23:22 -0600

> I wonder whether you can consider putting the document in the IETF LC for now. If it happen that we need to modify the 0-RTT text, we will handle it as other IETF LC comments.

I would normally be pretty amenable to starting IETF LC and continuing
discussion; it's just for this issue in particular that I seem to be the
main person on the IESG that enforces the "application profile for 0-RTT
data" requirement, so it would feel rather odd to go forward in this case.
Luckily, I spent some time this weekend reading RFC 7252 and have some
substantive comments.

The key oberservation here seems to be that the Message ID is scoped per
endpoint, and replays can come from arbitrary addresses.

Specifically, we recall that:

   The DOTS signal channel is layered on existing standards (Figure 3).

                          +---------------------+
                          | DOTS Signal Channel |
                          +---------------------+
                          |         CoAP        |
                          +----------+----------+
                          |   TLS    |   DTLS   |
                          +----------+----------+
                          |   TCP    |   UDP    |
                          +----------+----------+
                          |          IP         |
                          +---------------------+

We note that CoAP is using the IP address or "DTLS session" (arguably a
poorly chosen term) to identify a CoAP association and that Message IDs are
only used within the scope of such an association, it seems pretty clear
that an attacker able to replay TLS 1.3 0-RTT data will slice off the top
three lines of this figure and swap out the TCP/UDP/IP layers.  In the
absence of DTLS connection IDs, my understanding is that the "DTLS session"
is identified solely by the transport connection, just as for coap-not-s,
so by spoofing the source address, the attacker causes the replayed 0-RTT
data (and thus, CoAP request) to be interpreted as a new incoming coaps
connection.

Given that Message ID is only 16 bits and the servers accepting 0-RTT data
have potential to be quite busy, it does not seem workable to attempt to
use the incoming Message IDs as globally unique replay defense, as the risk
of collision would be pretty large.

So I think that the 'mid' monotonicity and the rejection of conflicting
request scopes are the main mitigating factors against replay in the
current design (alongside the RFC 8446 mechanisms, of course), and the text
should be adjusted to reflect that.

It seems that the 'mid' ordering is probably enough to protect
reordering/replay of mitigiation request and withdraw, even when reordered
across other mitigation actions.  But I am more concerned about
reordering/replay of other messages, like efficacy updates and session
configuration changes.

Consider

client                   attacker                    server
|
|----efficacy: attack mitigated--------------------->|
|                                                    |
|----efficacy: under attack------------------------->|
|                                                    |
|                        |-replay: attack mitigated->|

Is the server going to end up with the expected state?

-Ben

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 19 Feb 2019 06:40:30 +0000

Hi Ben,

Agree with you that Message IDs cannot be used as globally unique replay defense but the draft is using both Message ID and Token (or request ID) as unique relay defense within the DOTS server domain. CoAP allows the size of Token to be up to 8 bytes and is randomized (see https://tools.ietf.org/html/rfc7252#section-5.3.1). 

I also agree with you that 'mid' is not sufficient to detect all types of replay attacks and hence the DOTS signal channel is replying on Message ID and Token along-side the 0-RTT relay detection mechanisms in RFC 8446 to defend against attackers spoofing the DOTS client IP address and replaying the 0-RTT data.

Cheers,
-Tiru

> Sent: Monday, February 18, 2019 9:53 PM
> > I wonder whether you can consider putting the document in the IETF LC for
> now. If it happen that we need to modify the 0-RTT text, we will handle it as
> other IETF LC comments.
> 
> discussion; it's just for this issue in particular that I seem to be the main person
> on the IESG that enforces the "application profile for 0-RTT data" requirement,
> so it would feel rather odd to go forward in this case.
> We note that CoAP is using the IP address or "DTLS session" (arguably a poorly
> chosen term) to identify a CoAP association and that Message IDs are only used
> within the scope of such an association, it seems pretty clear that an attacker
> able to replay TLS 1.3 0-RTT data will slice off the top three lines of this figure
> and swap out the TCP/UDP/IP layers.  In the absence of DTLS connection IDs,
> my understanding is that the "DTLS session"
> is identified solely by the transport connection, just as for coap-not-s, so by
> spoofing the source address, the attacker causes the replayed 0-RTT data (and
> thus, CoAP request) to be interpreted as a new incoming coaps connection.
> 
> have potential to be quite busy, it does not seem workable to attempt to use
> the incoming Message IDs as globally unique replay defense, as the risk of
> collision would be pretty large.
> 
> So I think that the 'mid' monotonicity and the rejection of conflicting request
> scopes are the main mitigating factors against replay in the current design
> (alongside the RFC 8446 mechanisms, of course), and the text should be
> adjusted to reflect that.
> 
> > > De : Benjamin Kaduk [mailto:[email-masked]] Envoyé : vendredi 15
> > > février 2019 16:05 À : BOUCADAIR Mohamed TGI/OLN Cc : Konda,
> > > Short form: I need to think about it harder.  There's some
> > > indication that the CoAp Message ID is at the wrong level to protect
> > > the 0-RTT data, but I'm not sure yet.
> > >
> > > > > Envoyé : mardi 29 janvier 2019 14:32 À : Benjamin Kaduk Cc :
> > > > > Konda, Tirumaleswar Reddy;
> > > > > Objet : Using Early Data in DOTS (RE: [Dots] AD review of
> > > > > draft-ietf-
> > > dots-
> > > > > signal-channel)
> > > > >
> > > > > Hi Ben, all,
> > > > >
> > > > > We edited a short draft
> > > > > earlydata-00) to motivate the following text included in the
> > > > > signal
> > > channel
> > > > > draft:
> > > > >
> > > > > This text and also the Designated Expert guidelines are
> > > > > implemented in -
> > > 28.
> > > > > > > > > > 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
> > > > > > > > > > session-signal is perhaps an example of a document
> > > > > > > > > > that
> > > specifies
> > > > > > which
> > > > > > > > > > (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.)
> > > > > > > > > > mitigation would be safe.  (On first glance the
> > > > > > > > > > session-
> > > managemnet
> > > > > > bits
> > > > > > > > > would
> > > > > > > > > The draft only uses idempotent requests (GET, PUT and
> > > > > > > > > DELETE),
> > > and
> > > > > CoAP
> > > > > > > is
> > > > > > > > > https://tools.ietf.org/html/rfc7252#section-4.5) for
> > > > > > > > > both
> > > confirmable
> > > > > > and
> > > > > > > > >  [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
> > > > > > > > > carrying an
> > > old
> > > > > > > >       Section 8 of [RFC8446] discusses some mechanisms to
> > > > > > > > implement
> > > to
> > > > > > > >       limit the impact of replay attacks on 0-RTT data.
> > > > > > > > If the
> > > DOTS

---

From: <[email-masked]>
Date: Tue, 19 Feb 2019 07:59:29 +0000

Hi Ben, 

Please see inline. 

Cheers,
Med

> Envoyé : lundi 18 février 2019 17:23

[Med] Fair enough. 

>    The DOTS signal channel is layered on existing standards (Figure 3).

[Med] The replay detection relies on both Message ID and Token.

> should be adjusted to reflect that.

[Med] We do already have the following in the draft:

      The DOTS server(s) can use Message ID and
                                                 ^^^^^^^^^^^^^^^^^^

> reordering/replay of other messages, like efficacy updates and session

[Med] For the configuration changes, I don't expect the exchange to happen during an attack. The part of the text we are discussing is about mitigation requests. 

   o  0-RTT mode in which the DOTS client can authenticate itself and
      send DOTS mitigation request messages in the first message, thus
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      reducing handshake latency.

Putting that aside, we do have the following: 

   The PUT request with a higher numeric 'sid' value overrides the DOTS
   signal channel session configuration data installed by a PUT request
   with a lower numeric 'sid' value.  To avoid maintaining a long list
   of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST be
   automatically deleted and no longer available at the DOTS server.

Any replayed configuration change request will be discarded owing to the 'sid' checks. 

> Is the server going to end up with the expected state?

[Med] A general comment: The dots server uses the information conveyed in the efficacy update as a hint; it may but it is not required to rely on those requests to adjust its mitigation actions. 

If the two first status messages are bound to distinct "mids" and adjusted scopes, the replayed request will be discarded by the server thanks to the presence of If-Match option. The server does not maintain the request with the old mid.  

If, for some reason, the same mid is used and this flow is observed, the server will detect that the same Message ID and Token are reused again and then reject.  

> > > > > This text and also the Designated Expert guidelines are implemented
> in -
> > > 28.
> > > > > > > > > > every request include a single-use nonce, and all messages
> are
> > > 0-
> > > > > RTT
> > > > > > > safe.)
> > > > > > > > > anti-replay (e.g. an attacker replaying a 0-RTT data carrying
> an
> > > old

---

From: <[email-masked]>
Date: Tue, 26 Feb 2019 15:15:16 +0000

Hi Ben,

FWIW, a NEW text was added to -29 to cover the session configuration reply. 

Cheers,
Med

> De : BOUCADAIR Mohamed TGI/OLN
> Envoyé : mardi 19 février 2019 08:59
> À : 'Benjamin Kaduk'
> Objet : RE: Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf-
> dots-signal-channel)
> 
> Hi Ben,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> [Med] For the configuration changes, I don't expect the exchange to happen
> during an attack. The part of the text we are discussing is about mitigation
> requests.
> 
> [Med] A general comment: The dots server uses the information conveyed in the
> efficacy update as a hint; it may but it is not required to rely on those
> requests to adjust its mitigation actions.
> 
> If the two first status messages are bound to distinct "mids" and adjusted
> scopes, the replayed request will be discarded by the server thanks to the
> presence of If-Match option. The server does not maintain the request with
> the old mid.
> 
> If, for some reason, the same mid is used and this flow is observed, the
> server will detect that the same Message ID and Token are reused again and
> then reject.
> 
> >
> > -Ben
> >
> >
> > >
> > > > > > Objet : Using Early Data in DOTS (RE: [Dots] AD review of draft-
> ietf-
> > > > dots-
> > > > > > signal-channel)
> > > > > >
> > > > > > Hi Ben, all,
> > > > > >
> > > > > > We edited a short draft (https://tools.ietf.org/html/draft-
> boucadair-
> > > > dots-
> messages
> > > > > > > > > > > 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
> carrying
> > > > > > > > >       limit the impact of replay attacks on 0-RTT data.  If
> the
> > > > DOTS

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 27 Feb 2019 09:57:30 -0600

> Please see inline. 

Okay.  BTW, it is looking like this is the last topic to resolve before
starting IETF LC.  It's probably worth s/the exponent is 2/the base of the
exponent is 2/ in the next rev, though, just as a minor nit-fix.

> [Med] The replay detection relies on both Message ID and Token.

In stock CoAP, the Message ID and Token are used only with the context of a
specific transport association.  In order to use them for (D)TLS 1.3 replay
defense, we need to expand that context to a broader scope, and direct the
server to check the Message ID/Token globally (or at least within the scope
of a given 'cuid'/'cdid').  Since this would reflect a divergence from
normal CoAP, if we are going to rely on this sort of behavior, we must call
it out very loudly as specific to DOTS.

>       data, and accept 0-RTT data at most once.  Furthermore, 'mid'

Sorry for being unclear in my comment. I was intending to emphasize that
'mid' and scope are the *only* measures that actually mitigate against
0-RTT replay, and that we are wrong to have text that indicates anything
else is an effective anti-replay mechanism, at least given the present
design.  So I was trying to ask for the text about Message ID and Token to
be removed.  (Our subsequent discussion indicates that it would maybe also
work to expand on it instead of remove it, noting that DOTS is requiring
additional behavior not mandated by the CoAP spec.)

>       send DOTS mitigation request messages in the first message, thus

If we don't expect to do anything other than mitigation requests in 0-RTT,
then why don't we just limit the messages allowed in 0-RTT data to be such
mitigation request messages (and explicitly exclude session configuration)?
I am not going to insist on it, but that does seem like the simplest way
to resolve the question, at least from over here.

> Any replayed configuration change request will be discarded owing to the 'sid' checks. 

That does help, yes.  (I'm not sure whether I had confused myself that the
sid was for the abstract "DOTS session" that is roughly akin to the DTLS
association, or this was added in response to some of my earlier comments
and I failed to internalize it properly.  It shows up as new in the diff
from -25 to -29 that I'm looking at in preparation for starting IETF LC.)

> If, for some reason, the same mid is used and this flow is observed, the server will detect that the same Message ID and Token are reused again and then reject.  

Not if the replay comes from a different transport endpoint!  (But let's
keep this topic at the discussion above, as it's the same topic.)

-Ben

---

From: <[email-masked]>
Date: Thu, 28 Feb 2019 08:18:18 +0000

Hi Ben, 

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 27 février 2019 16:58

[Med] Fixed.

> specific transport association. 

[Med] Hmm...RFC7252 defines an endpoint as follows: 

   The specific definition of an endpoint depends on the transport being
   used for CoAP.  For the transports defined in this specification, the
   endpoint is identified depending on the security mode used (see
   Section 9): With no security, the endpoint is solely identified by an
   IP address and a UDP port number.  With other security modes, the
   endpoint is identified as defined by the security mode.

DOTS adheres to that definition: it assumes that an endpoint is not identified by its transport coordinates but with its identity. 

Furthermore, the correlation between sessions is clearly mentioned in the text:

   The DOTS server couples the DOTS signal channel sessions using the
   DOTS client identity and optionally the 'cdid' parameter value, and
   the DOTS server uses 'mid' and 'cuid' Uri-Path parameter values to
   detect duplicate mitigation requests.

 In order to use them for (D)TLS 1.3 replay
> it out very loudly as specific to DOTS.

[Med] We can make this change if it helps: 

OLD:
      The DOTS server(s) can use Message ID and
      Token in the DOTS signal channel message to detect replay of early
      data, and accept 0-RTT data at most once.

NEW:
      The DOTS server(s) can use Message ID and
      Token in the DOTS signal channel message to detect replay of early
      data, and accept 0-RTT data at most once from the same DOTS client.
      DOTS servers do not rely on transport coordinates to 
      identify its peers. As a reminder, DOTS servers couples the DOTS signal channel sessions 
      using the DOTS client identity and optionally the 'cdid' parameter value.

> That does help, yes.

[Med] OK.

  (I'm not sure whether I had confused myself that the
> > [Med] A general comment: The dots server uses the information conveyed in
> the efficacy update as a hint; it may but it is not required to rely on those
> > > > > On Fri, Feb 15, 2019 at 03:01:29PM +0000,
> [email-masked]
> > > wrote:
> > > > > > Hi Ben,
> > > > > >
> > > > > > >       in each CoAP request.  The DOTS server(s) can use Message
> ID
> > > and
> > > > > > >       Token in the DOTS signal channel message to detect replay
> of
> > > early
> > > > > > >       anti-replay mechanisms, all DOTS signal channel requests
> are
> > > safe
> implemented
> > > > > > > > > > > > safe (and why) or defer that profile to another
> document.
> > > > > draft-
> > > > > > > > ietf-
> > > > > > > > > > > dnsop-

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 28 Feb 2019 10:31:50 +0000

> Sent: Wednesday, February 27, 2019 9:28 PM
> Okay.  BTW, it is looking like this is the last topic to resolve before starting IETF
> LC.  It's probably worth s/the exponent is 2/the base of the exponent is 2/ in the
> next rev, though, just as a minor nit-fix.
> 
> >
> > > De : Benjamin Kaduk [mailto:[email-masked]] Envoyé : lundi 18 février
> > > 2019 17:23 À : BOUCADAIR Mohamed TGI/OLN Cc : Konda, Tirumaleswar
> > > Reddy; [email-masked];
> > > [email-masked]
> > > now. If it happen that we need to modify the 0-RTT text, we will
> > > handle it as other IETF LC comments.
> > >
> > > I would normally be pretty amenable to starting IETF LC and
> > > continuing discussion; it's just for this issue in particular that I
> > > seem to be the main person on the IESG that enforces the
> > > "application profile for 0-RTT data" requirement, so it would feel rather odd
> to go forward in this case.
> >
> > [Med] Fair enough.
> >
> > > Luckily, I spent some time this weekend reading RFC 7252 and have
> > > some substantive comments.
> > >
> > > The key oberservation here seems to be that the Message ID is scoped
> > > per endpoint, and replays can come from arbitrary addresses.
> > >
> > > We note that CoAP is using the IP address or "DTLS session"
> > > (arguably a poorly chosen term) to identify a CoAP association and
> > > that Message IDs are only used within the scope of such an
> > > association, it seems pretty clear that an attacker able to replay
> > > TLS 1.3 0-RTT data will slice off the top three lines of this figure
> > > is identified solely by the transport connection, just as for
> > > coap-not-s, so by spoofing the source address, the attacker causes
> > > the replayed 0-RTT data (and thus, CoAP request) to be interpreted
> > > as a new incoming coaps connection.
> > >
> > > Given that Message ID is only 16 bits and the servers accepting
> > > 0-RTT data have potential to be quite busy, it does not seem
> > > workable to attempt to use the incoming Message IDs as globally
> > > unique replay defense, as the risk of collision would be pretty large.
> >
> server to check the Message ID/Token globally (or at least within the scope of a
> given 'cuid'/'cdid').  Since this would reflect a divergence from normal CoAP, if
> we are going to rely on this sort of behavior, we must call it out very loudly as
> specific to DOTS.

Agreed.

> 
> > >
> > > So I think that the 'mid' monotonicity and the rejection of
> > > conflicting request scopes are the main mitigating factors against
> > > replay in the current design (alongside the RFC 8446 mechanisms, of
> > > course), and the text should be adjusted to reflect that.
> >
> Sorry for being unclear in my comment. I was intending to emphasize that 'mid'
> and scope are the *only* measures that actually mitigate against 0-RTT replay,
> and that we are wrong to have text that indicates anything else is an effective
> anti-replay mechanism, at least given the present design.  So I was trying to ask
> for the text about Message ID and Token to be removed.  (Our subsequent
> discussion indicates that it would maybe also work to expand on it instead of
> remove it, noting that DOTS is requiring additional behavior not mandated by
> the CoAP spec.)
> 
> > >
> > > reordering/replay of mitigiation request and withdraw, even when
> > > reordered across other mitigation actions.  But I am more concerned
> > > about reordering/replay of other messages, like efficacy updates and
> > > session configuration changes.
> >
> If we don't expect to do anything other than mitigation requests in 0-RTT, then
> why don't we just limit the messages allowed in 0-RTT data to be such
> I am not going to insist on it, but that does seem like the simplest way to
> resolve the question, at least from over here.

I like the proposal, avoids the need to share Message ID and Token sent in 0-RTT data among all the DOTS servers in the domain.  If the client uses a new 'mid' value (or a new mitigation request) every time a mitigation request is sent as 0-RTT data, sharing the 'mid' value sent in the 0-RTT data among the DOTS servers in the domain is sufficient to detect replay attacks. DOTS servers anyway have to co-ordinate and sync the mitigation requests, aliases and filtering rules. 

Cheers,
-Tiru

> That does help, yes.  (I'm not sure whether I had confused myself that the sid
> was for the abstract "DOTS session" that is roughly akin to the DTLS association,
> or this was added in response to some of my earlier comments and I failed to
> internalize it properly.  It shows up as new in the diff from -25 to -29 that I'm
> looking at in preparation for starting IETF LC.)
> 
> > >
> > > Consider
> > >
> > > client                   attacker                    server
> > > |
> presence of If-Match option. The server does not maintain the request with the
> old mid.
> >
> > If, for some reason, the same mid is used and this flow is observed, the server
> will detect that the same Message ID and Token are reused again and then
> reject.
> 
> Not if the replay comes from a different transport endpoint!  (But let's keep this
> topic at the discussion above, as it's the same topic.)
> 
> -Ben
> 
> > >
> > > -Ben
> > >
> > >
> > > >
> > > > > indication
> > > > > the CoAp Message ID is at the wrong level to protect the 0-RTT
> > > > > data, but I'm not sure yet.
> > > > >
> > > > > > > Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-
> > > [email-masked];
> > > > > > > [email-masked]
> > > > > > >       (Section 3 of [RFC7252]) is changed each time a new
> > > > > > > CoAP
> > > request
> > > > > > >       in each CoAP request.  The DOTS server(s) can use
> > > > > > > Message ID
> > > and
> > > > > > >       Token in the DOTS signal channel message to detect
> > > > > > > replay of
> > > early
> > > > > > >       mitigation request, attackers replaying mitigation
> > > > > > > requests
> > > with
> > > > > > >       Owing to the aforementioned protections, especially
> > > > > > > those
> > > afforded
> > > > > > >       anti-replay mechanisms, all DOTS signal channel
> > > > > > > requests are
> > > safe
> > > > > > > > > > > > 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
> > > > > > > > > > > > (draft-ietf-acme-acme is another, but an
> > > > > > > > > > > > uninteresting one,
> > > > > since
> > > > > > > > they
> > > > > > > > > make
> > > > > > > > > > > > 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
> > > > > > > > > >       limit the impact of replay attacks on 0-RTT
> > > > > > > > > > data.  If the
> > > > > DOTS
> > > > > > > > > >       server accepts 0-RTT, it MUST implement one of
> > > > > > > > > > these
> > > > > mechanisms

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 28 Feb 2019 10:49:48 +0000

> From: Dots <[email-masked]> On Behalf Of
> Sent: Thursday, February 28, 2019 1:48 PM
> To: Benjamin Kaduk <[email-masked]>
> Cc: [email-masked]; Konda, Tirumaleswar Reddy
> <[email-masked]>; [email-masked]
> Subject: Re: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-
> signal-channel)
> 
> > De : Benjamin Kaduk [mailto:[email-masked]] Envoyé : mercredi 27
> > février 2019 16:58 À : BOUCADAIR Mohamed TGI/OLN Cc : Konda,
> > Okay.  BTW, it is looking like this is the last topic to resolve
> > before starting IETF LC.  It's probably worth s/the exponent is 2/the
> > base of the exponent is 2/ in the next rev, though, just as a minor nit-fix.
> >
> 
> [Med] Fixed.
> 
> > >
> > > > De : Benjamin Kaduk [mailto:[email-masked]] Envoyé : lundi 18
> > > > février 2019 17:23 À : BOUCADAIR Mohamed TGI/OLN Cc : Konda,
> > > > Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf..org;
> > > > [email-masked]
> > > > On Fri, Feb 15, 2019 at 03:36:05PM +0000,
> > > > > I wonder whether you can consider putting the document in the
> > > > > IETF LC
> > for
> > it as
> > > > continuing discussion; it's just for this issue in particular that
> > > > I seem to be the main person on the IESG that enforces the
> > > > "application profile for 0-RTT data" requirement, so it would feel
> > > > rather odd to go forward in this
> > case.
> > >
> > > [Med] Fair enough.
> > >
> > > > The key oberservation here seems to be that the Message ID is
> > > > scoped per endpoint, and replays can come from arbitrary addresses.
> > > >
> > > > that Message IDs
> > > > only used within the scope of such an association, it seems pretty
> > > > clear that an attacker able to replay TLS 1.3 0-RTT data will
> > > > slice off the top three lines of this figure and swap out the
> > > > TCP/UDP/IP layers.  In the absence of DTLS connection IDs, my
> > > > understanding is that the "DTLS
> > session"
> > data
> > > > have potential to be quite busy, it does not seem workable to
> > > > attempt to use the incoming Message IDs as globally unique replay
> > > > defense, as the
> > risk
> > In stock CoAP, the Message ID and Token are used only with the context
> > of a specific transport association.
> 
> DOTS adheres to that definition: it assumes that an endpoint is not identified by
> its transport coordinates but with its identity.
> 
> > defense, we need to expand that context to a broader scope, and direct
> > the server to check the Message ID/Token globally (or at least within
> > the scope of a given 'cuid'/'cdid').  Since this would reflect a
> > divergence from normal CoAP, if we are going to rely on this sort of
> > behavior, we must call it out very loudly as specific to DOTS.
> >
> 

I propose to update the text as follows:

      The DOTS server(s) can use the Message ID and
      Token in the DOTS signal channel message to detect replay of early
      data, and accept 0-RTT data at most once from the same DOTS client.
      This anti-replay defense requires sharing the Message ID and Token in the 0-RTT data
      between DOTS servers in the DOTS server domain. 
      DOTS servers do not rely on transport coordinates to 
      identify its peers. As a reminder, DOTS servers couples the DOTS signal channel sessions 
      using the DOTS client identity and optionally the 'cdid' parameter value.

-Tiru

> > > > replay in the current design (alongside the RFC 8446 mechanisms,
> > > > of course), and the
> > text
> > Sorry for being unclear in my comment. I was intending to emphasize
> > that 'mid' and scope are the *only* measures that actually mitigate
> > against 0-RTT replay, and that we are wrong to have text that
> > indicates anything else is an effective anti-replay mechanism, at
> > least given the present design.  So I was trying to ask for the text
> > about Message ID and Token to be removed.  (Our subsequent discussion
> > indicates that it would maybe also work to expand on it instead of
> > remove it, noting that DOTS is requiring additional behavior not
> > mandated by the CoAP spec.)
> >
> > > >
> > reordered
> > > > reordering/replay of other messages, like efficacy updates and
> > during an attack. The part of the text we are discussing is about
> > mitigation requests.
> > >
> > If we don't expect to do anything other than mitigation requests in
> > 0-RTT, then why don't we just limit the messages allowed in 0-RTT data
> > to be such mitigation request messages (and explicitly exclude session
> configuration)?
> > I am not going to insist on it, but that does seem like the simplest
> > way to resolve the question, at least from over here.
> >
> > > Any replayed configuration change request will be discarded owing to
> > > the
> > 'sid' checks.
> >
> > That does help, yes.
> 
> [Med] OK.
> 
> > sid was for the abstract "DOTS session" that is roughly akin to the
> > DTLS association, or this was added in response to some of my earlier
> > comments and I failed to internalize it properly.  It shows up as new
> > in the diff from -25 to -29 that I'm looking at in preparation for
> > starting IETF LC.)
> >
> > > >
> > > > Consider
> > > >
> > > > client                   attacker                    server
> > > > |
> > the efficacy update as a hint; it may but it is not required to rely
> > on those requests to adjust its mitigation actions.
> > >
> > scopes, the replayed request will be discarded by the server thanks to
> > the presence of If-Match option. The server does not maintain the
> > request with the old mid.
> > >
> > server will detect that the same Message ID and Token are reused again
> > and then reject.
> >
> > Not if the replay comes from a different transport endpoint! (But
> > let's keep this topic at the discussion above, as it's the same
> > topic.)
> >
> > -Ben
> >
> > > >
> > > > -Ben
> > > >
> > > >
> > > > >
> > > > > > De : Benjamin Kaduk [mailto:[email-masked]] Envoyé : vendredi
> > > > > > 15 février 2019 16:05 À : BOUCADAIR Mohamed TGI/OLN Cc :
> > > > > > Objet : Re: Using Early Data in DOTS (RE: [Dots] AD review of
> > > > > > draft-
> > ietf-
> > > > > > dots-signal-channel)
> > > > > >
> > > > > > Hi Med,
> > > > > >
> > > > > > data,
> > but
> > > > > > > > -----Message d'origine----- De :
> > > > [mailto:[email-masked]]
> > > > > > > > Envoyé : mardi 29 janvier 2019 14:32 À : Benjamin Kaduk Cc
> > > > > > > > : Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-
> > > > [email-masked];
> > > > > > > > [email-masked]
> > > > > > > > (https://tools.ietf.org/html/draft-
> > boucadair-
> > > > > > dots-
> > > > > > > >       The DOTS signal channel messages sent as early data
> > > > > > > > by the
> > DOTS
> > > > > > > >       is sent, and the Token (Section 5.3.1 of [RFC7252])
> > > > > > > > is
> > > > randomized
> > > > > > > > Message
> > > > > > > > replay
> > > > > > > > Furthermore,
> > 'mid'
> > > > > > > >       value is monotonically increased by the DOTS client
> > > > > > > > for
> > each
> > > > > > > >       lower numeric 'mid' values and overlapping scopes
> > > > > > > > with
> > > > mitigation
> > > > > > > >       by CoAP deduplication (Section 4.5 of [RFC7252]) and
> > > > > > > > RFC
> > 8446
> > > > > > > > > > > > > Regarding the (D)TLS 1.3 0-RTT data, RFC 8446
> > > > > > > > > > > > > notes
> > that
> > > > > > > > "Application
> > > > > > > > > > > > > profile
> > > > > > > > > > > > > session-signal is perhaps an example of a
> > > > > > > > > > > > > document that
> > > > > > specifies
> > > > > > > > > which
> > > > > > > > > > > > > uninteresting
> > > > > > > > > > > > https://tools.ietf.org/html/rfc7252#section-4.5)
> > > > > > > > > > > > for both
> > > > > > confirmable
> > > > > > > > > and
> > > > > > > > > > > data.  If
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: <[email-masked]>
Date: Thu, 28 Feb 2019 13:08:57 +0000

Re-,

I rearranged the text as follows: 

OLD: 
      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.  As a reminder, 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]) is randomized
      in each CoAP request.  The DOTS server(s) can use Message ID and
      Token in the DOTS signal channel message to detect replay of early
      data, and accept 0-RTT data at most once.  Furthermore, 'mid'
      value is monotonically increased by the DOTS client for each
      mitigation request, attackers replaying mitigation requests with
      lower numeric 'mid' values and overlapping scopes with mitigation
      requests having higher numeric 'mid' values will be rejected
      systematically by the DOTS server.  Likewise, 'sid' value is
      monotonically increased by the DOTS client for each configuration
      session, attackers replaying configuration requests with lower
      numeric 'sid' values will be rejected by the DOTS server if it
      maintains a higher numeric 'sid' value for this DOTS client.

NEW:
      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 to
      prevent replay at the TLS layer.  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.  As a reminder, the 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]) is randomized
      in each CoAP request.  The DOTS server(s) MUST use the Message ID
      and the Token in the DOTS signal channel message to detect replay
      of early data at the application layer, and accept 0-RTT data at
      most once from the same DOTS client.  This anti-replay defense
      requires sharing the Message ID and the Token in the 0-RTT data
      between DOTS servers in the DOTS server domain.  DOTS servers do
      not rely on transport coordinates to identify DOTS peers.  As
      specified in Section 4.4.1, DOTS servers couple the DOTS signal
      channel sessions using the DOTS client identity and optionally the
      'cdid' parameter value.  Furthermore, 'mid' value is monotonically
      increased by the DOTS client for each mitigation request,
      attackers replaying mitigation requests with lower numeric 'mid'
      values and overlapping scopes with mitigation requests having
      higher numeric 'mid' values will be rejected systematically by the
      DOTS server.  Likewise, 'sid' value is monotonically increased by
      the DOTS client for each configuration request (Section 4.5.2),
      attackers replaying configuration requests with lower numeric
      'sid' values will be rejected by the DOTS server if it maintains a
      higher numeric 'sid' value for this DOTS client.

Cheers,
Med

> De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
> Envoyé : jeudi 28 février 2019 11:50
> À : BOUCADAIR Mohamed TGI/OLN; Benjamin Kaduk
> Cc : [email-masked]; [email-masked]
> Objet : RE: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-
> dots-signal-channel)
> 
> >       identify its peers. As a reminder, DOTS servers couples the DOTS
> signal
> > channel sessions