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

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

Updated text looks good to me. 
@Ben - Please let us know if the proposed update addresses your comments, we would like to publish the changes.

Cheers,
-Tiru

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Thursday, February 28, 2019 6:39 PM
> To: Konda, Tirumaleswar Reddy <[e-mail]>;
> Benjamin Kaduk <[e-mail]>
> Cc: [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.
> 
> 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