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

[Benjamin Kaduk <[e-mail]>]

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


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