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

[Benjamin Kaduk <[e-mail]>]

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.

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