Re: [Last-Call] [Emu] Secdir last call review of draft-ietf-emu-rfc7170bis-15

Alexander Clouter <alex+ietf@coremem.com> Mon, 04 March 2024 09:34 UTC

Return-Path: <alex+ietf@coremem.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D12FC14CEFF; Mon, 4 Mar 2024 01:34:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.806
X-Spam-Level:
X-Spam-Status: No, score=-2.806 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=coremem.com header.b="LWRzba/3"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="Yrm9Ejik"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdzVDYMwU9Ai; Mon, 4 Mar 2024 01:34:34 -0800 (PST)
Received: from wfhigh8-smtp.messagingengine.com (wfhigh8-smtp.messagingengine.com [64.147.123.159]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51AD1C14F747; Mon, 4 Mar 2024 01:34:34 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfhigh.west.internal (Postfix) with ESMTP id 99FB318000B6; Mon, 4 Mar 2024 04:34:32 -0500 (EST)
Received: from imap46 ([10.202.2.96]) by compute3.internal (MEProxy); Mon, 04 Mar 2024 04:34:33 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coremem.com; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1709544872; x=1709631272; bh=+wxvwxHe84 rqzCCvH5rch1U/D/XGVTblzi7k+yCetYk=; b=LWRzba/3KiJS3tJqa4u5eH9tN0 ttvM72FEMhTi8RSXkRAZEEhzF0Lk65dA6nhPgGvjySkcSgQ78MdjfZ/l5X0JXIyz Cif23rSxXWXAHjXG1ySDapZ0qeRIrZ12DZuYvOfYr2pS1fJ5cqnHKJnDF7MKpYu9 gPA/gC75Tzv6gM0+87Fotqyrymb/bbBjK5DIIeaPOs5rRXFpKIwH5R83PkwkwTf5 F/iPoooEZ4n+RWdy9NmBxJvL6CFtQbXDnIYXmy1shwzWys9j4frmrVFqeWhMPlp8 GaEsMDdlz+mDHD5468xnxMzeCZlcypk0m6ZTXmbgRZ2QkV+iqz+p+PPvinyg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1709544872; x=1709631272; bh=+wxvwxHe84rqzCCvH5rch1U/D/XG VTblzi7k+yCetYk=; b=Yrm9EjikEHB3Svq9jeXSjjn1TvJkaBz2pl5YKmpmPemy x1Xkm4e5uAsbCSGZdX9kKN8N6prLlAA98bNGn7Dveuxsf4pAecLzy4tv6OxVuQ8o T2CLM6mAwc4V9Hq7fOVb/Jctl/H9Lxv6dC51N6nXepox1rEadXSD6ucFx9jkF8Jt sBaayElBCZMCP5n5oeMgov0ad6tuKprf4P3NBU4/HRqgSaf6AzRVu/qCIQHSZccn 0JLAfBQxvN1AQfGa7UwXjqylICW1XHpme6qgEfvq+c4tOaSpw59yeUjNfZpiYR63 1j83PEjAu9xTjZt6OjQSunBx19X/ke1A8lbw64xnzw==
X-ME-Sender: <xms:p5XlZQkJ1_nr5pjnR5WyKSJvKEsjzna5EEQiAxhjAL8fj6eVZlJynw> <xme:p5XlZf0K7_xLtCBKJGWa95pZUqGFvz4nnWRmWrbwpxifxF80NH_6QcEDitlDeW0Np ImwmpW7Wq1wVcw7KQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrheejgddtgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdetlhgv gigrnhguvghrucevlhhouhhtvghrfdcuoegrlhgvgidoihgvthhfsegtohhrvghmvghmrd gtohhmqeenucggtffrrghtthgvrhhnpeevgeehjeeuveekvedvhfehuedufeehgeduuedt leelieetheegffeitedtudfgudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpegrlhgvgidoihgvthhfsegtohhrvghmvghmrdgtohhm
X-ME-Proxy: <xmx:p5XlZepTQ_SAaZ7xwyuo-k7r6yRJc_J4_B65hOQPJ_vH4gMWPHaORg> <xmx:p5XlZcliqgqjPai-nJMcUs88QqVSikyuOZEfOWqK0hrjYR61HvWTHw> <xmx:p5XlZe1p3DoeHCFjrfjNjWbgOBBSqdNde_qZj7toeRr4w2YJzIyX-g> <xmx:qJXlZa-pbwhZtCgh6u-DC3WTlX6J0rVSVy00VcQMmdq0n1PabyoA-ZFeu0U>
Feedback-ID: ie3614602:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id B896B2A20090; Mon, 4 Mar 2024 04:34:31 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.11.0-alpha0-205-g4dbcac4545-fm-20240301.001-g4dbcac45
MIME-Version: 1.0
Message-Id: <bc28880d-01b5-49fd-9f8d-2f16d5046bbf@app.fastmail.com>
In-Reply-To: <E6327251-F06D-4022-80B5-5AD6C85836E4@deployingradius.com>
References: <170934966282.22720.15728977796194077360@ietfa.amsl.com> <2A5A060E-241C-433E-A281-037BA1D53437@deployingradius.com> <c7a59cf9-b5f0-40bf-9c9b-496fdf89484a@app.fastmail.com> <E6327251-F06D-4022-80B5-5AD6C85836E4@deployingradius.com>
Date: Mon, 04 Mar 2024 09:34:11 +0000
From: Alexander Clouter <alex+ietf@coremem.com>
To: Alan DeKok <aland@deployingradius.com>
Cc: David Mandelberg <david@mandelberg.org>, secdir@ietf.org, draft-ietf-emu-rfc7170bis.all@ietf.org, EMU WG <emu@ietf.org>, last-call@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/c8cn9XBiJKtpgGx4JfQD-hZXzmY>
Subject: Re: [Last-Call] [Emu] Secdir last call review of draft-ietf-emu-rfc7170bis-15
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Mar 2024 09:34:39 -0000

On Sun, 3 Mar 2024, at 23:02, Alan DeKok wrote:
>> My proposal would be to just use a dummy (marked optional) Outer-TLV that would be ignored by the other end to avoid this problem; sort of like GREASE...but to fix an insecurity instead.
>
>   I think that changes existing implementations.  Unless the 
> recommendation is for each end to add a dummy Outer-TLV which 
> implementations are *known* to ignore.

It is completely optional to add this and it is marked as an 'optional' TLV so will have no  impact to existing implementations.

The document already states that if you receive an *optional* TLV you do not understand, just ignore it.

For people who think this attack may be a problem, they have the option to append effectively a NOP TLV could solve this.

I think providing someone with an option is a good thing. It is fine for *us* to state "this if perfectly okay though" but someone else may find that harder to eat so if they want to do this extra thing nothing prevents them.

Of course we could add a new TLV with no problems (it is marked optional) or more dirty we suggest the implementor picks something in their own Vendor TLV space. Alternatively we meditate on using Vendor-ID 0 or someone donates?

Cheers