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

[<[e-mail]>]

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