Re: [Dots] AD review of draft-ietf-dots-rfc8782-bis-04

mohamed.boucadair@orange.com Wed, 03 March 2021 06:59 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 5F7853A1B72; Tue, 2 Mar 2021 22:59:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
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 vrFXKlsi-lB4; Tue, 2 Mar 2021 22:59:29 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DEC53A1B74; Tue, 2 Mar 2021 22:59:29 -0800 (PST)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 4Dr4cJ01jLzCrjG; Wed, 3 Mar 2021 07:59:28 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1614754768; bh=rxFu0zLDIuOUnf8gKccxk3y5lVI4GrDbawVODiQAikY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Q34LDmzV31p7mK+omIrir6M0J0n1TLrFGGxivFfE8Dc2o60tD1vGiaifTe9Bl0Ga4 nva0QvxjS0NxICfs7lh8tYTmFaC8oGQNazuSmXABZCLDBAOjY2sWoR1J3LskGw1hpo aQJxTMuIZv7hcrpY54TAAqHkteCgWwR/cejSEn5KDY/9Ke5qPgIHf3TtinqHh6xYxb dnHIB3iU15o6ovW0l6InEcyrSPGrAgeEwdmzeDZ27/BCK1xJVUEHZwlS3Q3gMAhl1Q A2UGAorkzGG+z/IiEQsybLj00rL+YaFLf81/P67ngu0YzLUgsW+kmHwZl9j8D6AEv9 RbTKRDos+1OvA==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.86]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 4Dr4cH6LDzz8sYf; Wed, 3 Mar 2021 07:59:27 +0100 (CET)
From: <mohamed.boucadair@orange.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: "draft-ietf-dots-rfc8782-bis.all@ietf.org" <draft-ietf-dots-rfc8782-bis.all@ietf.org>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] AD review of draft-ietf-dots-rfc8782-bis-04
Thread-Index: AQHXD95DkZalG/dfAEaZM0TRCDZqV6pxzizw
Date: Wed, 3 Mar 2021 06:59:27 +0000
Message-ID: <8819_1614754767_603F33CF_8819_314_1_787AE7BB302AE849A7480A190F8B9330315E7B7E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <20210301220755.GK21@kduck.mit.edu> <22059_1614696105_603E4EA9_22059_10_1_787AE7BB302AE849A7480A190F8B9330315DBE21@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20210303033521.GY21@kduck.mit.edu>
In-Reply-To: <20210303033521.GY21@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/PUsrFgVsxIZdOe-6yMRLHkGRf5U>
Subject: Re: [Dots] AD review of draft-ietf-dots-rfc8782-bis-04
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: Wed, 03 Mar 2021 06:59:31 -0000

Hi Ben, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:kaduk@mit.edu]
> Envoyé : mercredi 3 mars 2021 04:35
> À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>
> Cc : draft-ietf-dots-rfc8782-bis.all@ietf.org; dots@ietf.org
> Objet : Re: [Dots] AD review of draft-ietf-dots-rfc8782-bis-04
> 
> Hi Med,
> 
> On Tue, Mar 02, 2021 at 02:41:38PM +0000,
> mohamed.boucadair@orange.com wrote:
> > Hi Ben,
> >
> > Thank you for the review.
> >
> > A diff is available at
> > https://www.ietf.org/rfcdiff?url1=draft-ietf-dots-rfc8782-
> bis&url2=htt
> > ps://raw.githubusercontent.com/boucadair/rfc8782-yang-
> update/master/dr
> > aft-ietf-dots-rfc8782-bis.txt
> >
> > Also updated 7049 to 8949 (and sections).
> 
> Thanks!
> It is okay (but not required) to submit a -05 with the pending
> changes once draft submission reopens.
> 
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Dots [mailto:dots-bounces@ietf.org] De la part de Benjamin
> > > Kaduk Envoyé : lundi 1 mars 2021 23:08 À :
> > > draft-ietf-dots-rfc8782-bis.all@ietf.org
> > > Cc : dots@ietf.org
> > > Objet : [Dots] AD review of draft-ietf-dots-rfc8782-bis-04
> > >
> > > Hi all,
> > >
> > > Sorry to have taken so long on this one -- I opened it up a
> couple
> > > times thinking "I'll just look at the diff from 8782; it'll be
> > > easy", but then halfway in I realized I did actually want to give
> > > some careful attention to the YANG changes and ran out of time.
> > >
> > > The good news is that it's generally in good shape -- I'll
> request
> > > the IETF LC (it will be extended due to the IETF 110 overlap) and
> > > the following comments can be considered along with the last-call
> > > comments.
> > >
> > > Thanks for the good work!
> > >
> > > -Ben
> > >
> > >
> > > We'll have to bump the copyright year in the YANG because I was
> too
> > > slow at processing this :(
> > >
> > > Should we say anything about what an implementation should do if
> it
> > > receives cuid/cdid/mid/sid in the payload body (e.g., ignore it
> or
> > > check for consistency with the received URI-Path)?
> >
> > [Med] We do already have the following:
> >
> >    'cuid' and 'mid' MUST NOT appear in the PUT request message body
> >    (Figure 6).
> >
> > and
> >
> >    If the request is missing a mandatory attribute, does not
> include
> >    'cuid' or 'mid' Uri-Path options, includes multiple 'scope'
> >    parameters, or contains invalid or unknown parameters, the DOTS
> >                   ^^^^^^^^^^^^^^^^
> >    server MUST reply with 4.00 (Bad Request).
> 
> Ah, I see now.  Should this be mentioned in the backwards-
> compatibility considerations section as something that would need to
> be relaxed for an 8782bis server to accept requests from an 8782
> client?

[Med] No, for the simple reason that we had the behavior I quoted in 8782 as well. We don't change the protocol. 

> > >                list acl-list {
> > >                  when "../../conflict-cause ="
> > >                     + " 'conflict-with-acceptlist'";
> > >                  key "acl-name";
> > >                  description
> > >                    "List of conflicting ACLs as defined in the
> DOTS
> > > data
> > >                     channel.  These ACLs are uniquely defined by
> > >                     cuid and acl-name.";
> > >
> > > Now that cuid is moved out of the structure and into the Uri-Path
> > > option, we have a new opportunity for separability of payload and
> > > metadata. The security considerations should discuss what
> prevents a
> > > "slice and dice" attack that uses a given payload on a different
> > > connection or in a different context such that it is interprted
> in
> > > the context of a different cuid.  (DTLS ought to be enough,
> assuming
> > > a request or response does not get split across datagrams.)
> >
> > [Med] Not sure if there is much to add because this falls under
> this text:
> >
> >    If the 'cuid' is guessable, a misbehaving DOTS client from
> within the
> >    client's domain can use the 'cuid' of another DOTS client of the
> >    domain to delete or alter active mitigations.  For this attack
> vector
> >    to happen, the misbehaving client needs to pass the security
> >    validation checks by the DOTS server, and eventually the checks
> of a
> >    client-domain DOTS gateway.
> >
> >    A similar attack can be achieved by a compromised DOTS client
> that
> >    can sniff the TLS 1.2 handshake, use the client certificate to
> >    identify the 'cuid' used by another DOTS client.  This attack is
> not
> >    possible if algorithms such as version 4 Universally Unique
> >    IDentifiers (UUIDs) in Section 4.4 of [RFC4122] are used to
> generate
> >    the 'cuid' because such UUIDs are not a deterministic function
> of the
> >    client certificate.  Likewise, this attack is not possible with
> TLS
> >    1.3 because most of the TLS handshake is encrypted and the
> client
> >    certificate is not visible to eavesdroppers.
> 
> I am not sure that this quite covers the class of scenario I had in
> mind.

[Med] I thought you were referring to an attack where, given that the full DOTS message can't be accessed, a compromised (legitimate) client can interfere with the actions of another client of the same domain. For that one to happen, the compromised client gas to guess the cuid and so on.

> Consider an on-path attacker that wants to rewrite a legitimate
> request from a real client.  The 'cuid' in the request would be the
> valid one corresponding to the real client, but a request payload
> from a different connection would be substituted in.
> 
> My understanding is that this doesn't work because we use channel
> security, so the attacker cannot modify just part of the data payload
> or cause (part
> of) a message from one connection to be interpreted as part of the
> other connection.  I was wondering if we should say that we rely on
> the transport security to keep the Uri-Path metadata and the encoded
> YANG structure tightly bound together.  Though, now that I say that
> ... it might be a little silly to call that out explicitly.
> 

[Med] :-) 

I don't think a change is needed.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.