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

[<[e-mail]>]

Re-,

I rearranged the text as follows: 

OLD: 
      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.  Likewise, 'sid' value is
      monotonically increased by the DOTS client for each configuration
      session, attackers replaying configuration requests with lower
      numeric 'sid' values will be rejected by the DOTS server if it
      maintains a higher numeric 'sid' value for this DOTS client.

NEW:
      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 to
      prevent replay at the TLS layer.  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, the 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) MUST use the Message ID
      and the Token in the DOTS signal channel message to detect replay
      of early data at the application layer, and accept 0-RTT data at
      most once from the same DOTS client.  This anti-replay defense
      requires sharing the Message ID and the Token in the 0-RTT data
      between DOTS servers in the DOTS server domain.  DOTS servers do
      not rely on transport coordinates to identify DOTS peers.  As
      specified in Section 4.4.1, DOTS servers couple the DOTS signal
      channel sessions using the DOTS client identity and optionally the
      'cdid' parameter value.  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.  Likewise, 'sid' value is monotonically increased by
      the DOTS client for each configuration request (Section 4.5.2),
      attackers replaying configuration requests with lower numeric
      'sid' values will be rejected by the DOTS server if it maintains a
      higher numeric 'sid' value for this DOTS client.

Cheers,
Med

> -----Message d'origine-----
> De : Konda, Tirumaleswar Reddy [mailto:[e-mail]]
> Envoyé : jeudi 28 février 2019 11:50
> À : BOUCADAIR Mohamed TGI/OLN; Benjamin Kaduk
> Cc : [e-mail]; [e-mail]
> Objet : RE: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-
> dots-signal-channel)
> 
> > -----Original Message-----
> > From: Dots <[e-mail]> On Behalf Of
> > [e-mail]
> > Sent: Thursday, February 28, 2019 1:48 PM
> > To: Benjamin Kaduk <[e-mail]>
> > Cc: [e-mail]; Konda, Tirumaleswar Reddy
> > <[e-mail]>; [e-mail]
> > Subject: Re: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-
> dots-
> > signal-channel)
> >
> > This email originated from outside of the organization. Do not click links
> or
> > open attachments unless you recognize the sender and know the content is
> safe.
> >
> > Hi Ben,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Benjamin Kaduk [mailto:[e-mail]] Envoyé : mercredi 27
> > > février 2019 16:58 À : 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 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.
> > >
> >
> > [Med] Fixed.
> >
> > > >
> > > > > -----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; draft-ietf-dots-signal-channel@ietf..org;
> > > > > [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.
> >
> > [Med] Hmm...RFC7252 defines an endpoint as follows:
> >
> >    The specific definition of an endpoint depends on the transport being
> >    used for CoAP.  For the transports defined in this specification, the
> >    endpoint is identified depending on the security mode used (see
> >    Section 9): With no security, the endpoint is solely identified by an
> >    IP address and a UDP port number.  With other security modes, the
> >    endpoint is identified as defined by the security mode.
> >
> > DOTS adheres to that definition: it assumes that an endpoint is not
> identified by
> > its transport coordinates but with its identity.
> >
> > Furthermore, the correlation between sessions is clearly mentioned in the
> text:
> >
> >    The DOTS server couples the DOTS signal channel sessions using the
> >    DOTS client identity and optionally the 'cdid' parameter value, and
> >    the DOTS server uses 'mid' and 'cuid' Uri-Path parameter values to
> >    detect duplicate mitigation requests.
> >
> >
> >  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.
> > >
> >
> > [Med] We can make this change if it helps:
> >
> > OLD:
> >       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.
> >
> > NEW:
> >       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 from the same DOTS client.
> >       DOTS servers do not rely on transport coordinates to
> >       identify its peers. As a reminder, DOTS servers couples the DOTS
> signal
> > channel sessions
> >       using the DOTS client identity and optionally the 'cdid' parameter
> value.
> 
> I propose to update the text as follows:
> 
>       The DOTS server(s) can use the Message ID and
>       Token in the DOTS signal channel message to detect replay of early
>       data, and accept 0-RTT data at most once from the same DOTS client.
>       This anti-replay defense requires sharing the Message ID and Token in
> the 0-RTT data
>       between DOTS servers in the DOTS server domain.
>       DOTS servers do not rely on transport coordinates to
>       identify its peers. As a reminder, DOTS servers couples the DOTS signal
> channel sessions
>       using the DOTS client identity and optionally the 'cdid' parameter
> value.
> 
> -Tiru