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

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

> -----Original Message-----
> From: Dots <[e-mail]> On Behalf Of
> [e-mail]
> Sent: Thursday, February 28, 2019 1:48 PM
> To: Benjamin Kaduk <[e-mail]>
> Cc: [e-mail]; Konda, Tirumaleswar Reddy
> <[e-mail]>; [e-mail]
> Subject: Re: [Dots] Using Early Data in DOTS (RE: 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 Ben,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Benjamin Kaduk [mailto:[e-mail]] Envoyé : mercredi 27
> > février 2019 16:58 À : BOUCADAIR Mohamed TGI/OLN Cc : Konda,
> > Tirumaleswar Reddy; [e-mail];
> > [e-mail]
> > Objet : Re: Using Early Data in DOTS (RE: [Dots] AD review of
> > draft-ietf-
> > dots-signal-channel)
> >
> > On Tue, Feb 19, 2019 at 07:59:29AM +0000,
> [e-mail] wrote:
> > > Hi Ben,
> > >
> > > 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] Fixed.
> 
> > >
> > > > -----Message d'origine-----
> > > > De : Benjamin Kaduk [mailto:[e-mail]] Envoyé : lundi 18
> > > > février 2019 17:23 À : BOUCADAIR Mohamed TGI/OLN Cc : Konda,
> > > > Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf..org;
> > > > [e-mail]
> > > > Objet : Re: Using Early Data in DOTS (RE: [Dots] AD review of
> > > > draft-ietf-
> > > > dots-signal-channel)
> > > >
> > > > On Fri, Feb 15, 2019 at 03:36:05PM +0000,
> > > > [e-mail]
> > wrote:
> > > > > 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.
> > > >
> > > > 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.
> > > >
> > > > 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.
> > >
> > > [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.
> 
> [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
> > 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.
> >
> 
> [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.

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

> 
> > > >
> > > > 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.
> > >
> > > [Med] We do already have the following in the draft:
> > >
> > >       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.
> >
> > 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.)
> >
> > > >
> > > > 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.
> > >
> > > [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.
> >
> > 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.
> >
> > > 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.
> >
> > That does help, yes.
> 
> [Med] OK.
> 
>   (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
> > > > |
> > > > |----efficacy: attack mitigated--------------------->|
> > > > |                                                    |
> > > > |----efficacy: under attack------------------------->|
> > > > |                                                    |
> > > > |                        |-replay: attack mitigated->|
> > > >
> > > > 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.
> >
> > 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
> > > >
> > > >
> > > > >
> > > > > > -----Message d'origine-----
> > > > > > De : Benjamin Kaduk [mailto:[e-mail]] Envoyé : vendredi
> > > > > > 15 février 2019 16:05 À : BOUCADAIR Mohamed TGI/OLN Cc :
> > > > > > Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-
> > [e-mail];
> > > > > > [e-mail]
> > > > > > Objet : Re: Using Early Data in DOTS (RE: [Dots] AD review of
> > > > > > draft-
> > ietf-
> > > > > > dots-signal-channel)
> > > > > >
> > > > > > 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
> > > > > >
> > > > > > On Fri, Feb 15, 2019 at 03:01:29PM +0000,
> > [e-mail]
> > > > wrote:
> > > > > > > Hi Ben,
> > > > > > >
> > > > > > > What is the status for this one? Are we OK to move forward?
> > > > > > >
> > > > > > > Thank you.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Med
> > > > > > >
> > > > > > > > -----Message d'origine----- De :
> > > > > > > > [e-mail]
> > > > [mailto:[e-mail]]
> > > > > > > > Envoyé : mardi 29 janvier 2019 14:32 À : Benjamin Kaduk Cc
> > > > > > > > : Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-
> > > > [e-mail];
> > > > > > > > [e-mail]
> > > > > > > > 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
> 
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots