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

<mohamed.boucadair@orange.com> Thu, 28 February 2019 08:18 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E97130DF6; Thu, 28 Feb 2019 00:18:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sMAFxkaR4bl; Thu, 28 Feb 2019 00:18:22 -0800 (PST)
Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C604012D4E7; Thu, 28 Feb 2019 00:18:21 -0800 (PST)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 4495636VbCz2xl2; Thu, 28 Feb 2019 09:18:19 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.76]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 4495635k31zBrLG; Thu, 28 Feb 2019 09:18:19 +0100 (CET)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7E.corporate.adroot.infra.ftgroup ([fe80::54f9:a664:e400:452a%21]) with mapi id 14.03.0435.000; Thu, 28 Feb 2019 09:18:19 +0100
From: mohamed.boucadair@orange.com
To: Benjamin Kaduk <kaduk@mit.edu>
CC: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>, "draft-ietf-dots-signal-channel@ietf.org" <draft-ietf-dots-signal-channel@ietf.org>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf-dots-signal-channel)
Thread-Index: AQHUzrUqRGWVfXoV+kCvM9AjMnGoAqX0wcIQ
Date: Thu, 28 Feb 2019 08:18:18 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA2680B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B93302EA0EC85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA20112@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190215150458.GV56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA20406@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190218162322.GI24387@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA21AC0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190227155729.GL53396@kduck.mit.edu>
In-Reply-To: <20190227155729.GL53396@kduck.mit.edu>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/L5TgHauB8_Dvr8fdZoOTlLFRdwM>
Subject: Re: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-signal-channel)
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Feb 2019 08:18:26 -0000

Hi Ben, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:kaduk@mit.edu]
> Envoyé : mercredi 27 février 2019 16:58
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf.org;
> dots@ietf.org
> 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, mohamed.boucadair@orange.com 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:kaduk@mit.edu]
> > > Envoyé : lundi 18 février 2019 17:23
> > > À : BOUCADAIR Mohamed TGI/OLN
> > > Cc : Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf.org;
> > > dots@ietf.org
> > > 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, mohamed.boucadair@orange.com
> 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.

> > >
> > > 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.
> 
> Sorry for being unclear in my comment. I was intending to emphasize that
> 'mid' and scope are the *only* measures that actually mitigate against
> 0-RTT replay, and that we are wrong to have text that indicates anything
> else is an effective anti-replay mechanism, at least given the present
> design.  So I was trying to ask for the text about Message ID and Token to
> be removed.  (Our subsequent discussion indicates that it would maybe also
> work to expand on it instead of remove it, noting that DOTS is requiring
> additional behavior not mandated by the CoAP spec.)
> 
> > >
> > > 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.
> 
> If we don't expect to do anything other than mitigation requests in 0-RTT,
> then why don't we just limit the messages allowed in 0-RTT data to be such
> mitigation request messages (and explicitly exclude session configuration)?
> I am not going to insist on it, but that does seem like the simplest way
> to resolve the question, at least from over here.
> 
> > 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.
> 
> That does help, yes.

[Med] OK.

  (I'm not sure whether I had confused myself that the
> sid was for the abstract "DOTS session" that is roughly akin to the DTLS
> association, or this was added in response to some of my earlier comments
> and I failed to internalize it properly.  It shows up as new in the diff
> from -25 to -29 that I'm looking at in preparation for starting IETF LC.)
> 
> > >
> > > 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.
> 
> Not if the replay comes from a different transport endpoint! (But let's
> keep this topic at the discussion above, as it's the same topic.)
> 
> -Ben
> 
> > >
> > > -Ben
> > >
> > >
> > > >
> > > > > -----Message d'origine-----
> > > > > De : Benjamin Kaduk [mailto:kaduk@mit.edu]
> > > > > Envoyé : vendredi 15 février 2019 16:05
> > > > > À : BOUCADAIR Mohamed TGI/OLN
> > > > > Cc : Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-
> channel@ietf.org;
> > > > > dots@ietf.org
> > > > > 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,
> mohamed.boucadair@orange.com
> > > wrote:
> > > > > > Hi Ben,
> > > > > >
> > > > > > What is the status for this one? Are we OK to move forward?
> > > > > >
> > > > > > Thank you.
> > > > > >
> > > > > > Cheers,
> > > > > > Med
> > > > > >
> > > > > > > -----Message d'origine-----
> > > > > > > De : mohamed.boucadair@orange.com
> > > [mailto:mohamed.boucadair@orange.com]
> > > > > > > Envoyé : mardi 29 janvier 2019 14:32
> > > > > > > À : Benjamin Kaduk
> > > > > > > Cc : Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-
> > > channel@ietf.org;
> > > > > > > dots@ietf.org
> > > > > > > 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