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

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

> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> Sent: Wednesday, February 27, 2019 9:28 PM
> To: [e-mail]
> Cc: Konda, Tirumaleswar Reddy <[e-mail]>;
> [e-mail]; [e-mail]
> Subject: 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.
> 
> >
> > > -----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; [e-mail];
> > > [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.  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.

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

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

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