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

[<[e-mail]>]

Hi Ben,

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

Cheers,
Med

> -----Message d'origine-----
> De : BOUCADAIR Mohamed TGI/OLN
> Envoyé : mardi 19 février 2019 08:59
> À : 'Benjamin Kaduk'
> 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 Ben,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----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.
> 
> >
> > 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.
> 
> >
> > 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.
> 
> 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.
> 
> >
> > 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.
> 
> >
> > -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