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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

Hi Ben,

Agree with you that Message IDs cannot be used as globally unique replay defense but the draft is using both Message ID and Token (or request ID) as unique relay defense within the DOTS server domain. CoAP allows the size of Token to be up to 8 bytes and is randomized (see https://tools.ietf.org/html/rfc7252#section-5.3.1). 

I also agree with you that 'mid' is not sufficient to detect all types of replay attacks and hence the DOTS signal channel is replying on Message ID and Token along-side the 0-RTT relay detection mechanisms in RFC 8446 to defend against attackers spoofing the DOTS client IP address and replaying the 0-RTT data.

Cheers,
-Tiru

> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> Sent: Monday, February 18, 2019 9:53 PM
> To: [e-mail]
> Cc: Konda, Tirumaleswar Reddy <[e-mail]>;
> [e-mail]; [e-mail]
> Subject: Re: Using Early Data in DOTS (RE: [Dots] 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.
> 
> 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