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: AQHUx6ZJ1F7LXcjiyEyakQdm0IXWmKXmq4XA
Date: Tue, 19 Feb 2019 07:59:29 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA21AC0@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>
In-Reply-To: <20190218162322.GI24387@kduck.mit.edu>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
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/JM2frpNXT76hT0cLK6iWXQ2OqwM>
Subject: Re: [Dots] Using Early Data in DOTS (RE: AD review of
 draft-ietf-dots-signal-channel)
Precedence: list

Hi Ben,=20

Please see inline.=20

Cheers,
Med

> -----Message d'origine-----
> De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu]
> Envoy=E9=A0: lundi 18 f=E9vrier 2019 17:23
> =C0=A0: BOUCADAIR Mohamed TGI/OLN
> Cc=A0: Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf.org=
;
> dots@ietf.org
> Objet=A0: Re: Using Early Data in DOTS (RE: [Dots] AD review of draft-iet=
f-
> dots-signal-channel)
>=20
> On Fri, Feb 15, 2019 at 03:36:05PM +0000, mohamed.boucadair@orange.com wr=
ote:
> > Re-,
> >
> > Looking forward to discuss this further.
> >
> > I wonder whether you can consider putting the document in the IETF LC f=
or
> now. If it happen that we need to modify the 0-RTT text, we will handle i=
t as
> other IETF LC comments.
>=20
> 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.=20

> Luckily, I spent some time this weekend reading RFC 7252 and have some
> substantive comments.
>=20
> The key oberservation here seems to be that the Message ID is scoped per
> endpoint, and replays can come from arbitrary addresses.
>=20
> Specifically, we recall that:
>=20
>    The DOTS signal channel is layered on existing standards (Figure 3).
>=20
>                           +---------------------+
>                           | DOTS Signal Channel |
>                           +---------------------+
>                           |         CoAP        |
>                           +----------+----------+
>                           |   TLS    |   DTLS   |
>                           +----------+----------+
>                           |   TCP    |   UDP    |
>                           +----------+----------+
>                           |          IP         |
>                           +---------------------+
>=20
> 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 a=
re
> 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 sessio=
n"
> 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.
>=20
> Given that Message ID is only 16 bits and the servers accepting 0-RTT dat=
a
> 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 ri=
sk
> of collision would be pretty large.

[Med] The replay detection relies on both Message ID and Token.

>=20
> 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 te=
xt
> 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.

>=20
> It seems that the 'mid' ordering is probably enough to protect
> reordering/replay of mitigiation request and withdraw, even when reordere=
d
> 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 mitigatio=
n requests.=20

   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.

Putting that aside, we do have the following:=20

   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 's=
id' checks.=20

>=20
> Consider
>=20
> client                   attacker                    server
> |
> |----efficacy: attack mitigated--------------------->|
> |                                                    |
> |----efficacy: under attack------------------------->|
> |                                                    |
> |                        |-replay: attack mitigated->|
>=20
> Is the server going to end up with the expected state?

[Med] A general comment: The dots server uses the information conveyed in t=
he efficacy update as a hint; it may but it is not required to rely on thos=
e requests to adjust its mitigation actions.=20

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. =20

If, for some reason, the same mid is used and this flow is observed, the se=
rver will detect that the same Message ID and Token are reused again and th=
en reject. =20

>=20
> -Ben
>=20
>=20
> >
> > > -----Message d'origine-----
> > > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu]
> > > Envoy=E9=A0: vendredi 15 f=E9vrier 2019 16:05
> > > =C0=A0: BOUCADAIR Mohamed TGI/OLN
> > > Cc=A0: Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf=
.org;
> > > dots@ietf.org
> > > Objet=A0: 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.co=
m
> wrote:
> > > > Hi Ben,
> > > >
> > > > What is the status for this one? Are we OK to move forward?
> > > >
> > > > Thank you.
> > > >
> > > > Cheers,
> > > > Med
> > > >
> > > > > -----Message d'origine-----
> > > > > De=A0: mohamed.boucadair@orange.com
> [mailto:mohamed.boucadair@orange.com]
> > > > > Envoy=E9=A0: mardi 29 janvier 2019 14:32
> > > > > =C0=A0: Benjamin Kaduk
> > > > > Cc=A0: Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-
> channel@ietf.org;
> > > > > dots@ietf.org
> > > > > Objet=A0: 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-boucad=
air-
> > > dots-
> > > > > earlydata-00) to motivate the following text included in the sign=
al
> > > channel
> > > > > draft:
> > > > >
> > > > >       Section 8 of [RFC8446] discusses some mechanisms to impleme=
nt
> to
> > > > >       limit the impact of replay attacks on 0-RTT data.  If the D=
OTS
> > > > >       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 I=
D
> and
> > > > >       Token in the DOTS signal channel message to detect replay o=
f
> early
> > > > >       data, and accept 0-RTT data at most once.  Furthermore, 'mi=
d'
> > > > >       value is monotonically increased by the DOTS client for eac=
h
> > > > >       mitigation request, attackers replaying mitigation requests
> with
> > > > >       lower numeric 'mid' values and overlapping scopes with
> mitigation
> > > > >       requests having higher numeric 'mid' values will be rejecte=
d
> > > > >       systematically by the DOTS server.
> > > > >
> > > > >       Owing to the aforementioned protections, especially those
> afforded
> > > > >       by CoAP deduplication (Section 4.5 of [RFC7252]) and RFC 84=
46
> > > > >       anti-replay mechanisms, all DOTS signal channel requests ar=
e
> 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 implement=
ed
> 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 tha=
t
> > > > > "Application
> > > > > > > > > > protocols MUST NOT use 0-RTT data without a profile tha=
t
> > > 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 ser=
ver
> > > 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 documen=
t.
> > > 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 messa=
ges
> are
> > > 0-
> > > > > RTT
> > > > > > > safe.)
> > > > > > > > > > Our use of increasing 'mid' values may help here, in te=
rms
> of
> > > > > > allowing
> > > > > > > > > DELETEs
> > > > > > > > > > to be safe, but I'd have to think a little more to be s=
ure
> 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 adver=
se
> > > impact,
> > > > > > 2.02
> > > > > > > > > (Deleted) Response Code is returned even if the mitigatio=
n
> > > request
> > > > > does
> > > > > > > not
> > > > > > > > > exist.
> > > > > > > > > [2] The techniques discussed in Section 8 of RFC8446 shou=
ld
> > > suffice
> > > > > to
> > > > > > > handle
> > > > > > > > > anti-replay (e.g. an attacker replaying a 0-RTT data carr=
ying
> 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