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

[Benjamin Kaduk <[e-mail]>]

Please go ahead and publish -- this is good enough for me to be willing to
start the IETF LC, though we will probably tweak it a bit more still.
(I'd like to keep the data channel and signal channel docs together through
IETF LC and IESG evaluation to the extent possible.)

-Ben

On Mon, Mar 04, 2019 at 04:01:47PM +0000, Konda, Tirumaleswar Reddy wrote:
> 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