IETF Logo Mail Archive

Re: [Lake] Ways forward on MTI cipher suite text

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 25 January 2022 16:01 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034793A0D67 for <lake@ietfa.amsl.com>; Tue, 25 Jan 2022 08:01:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
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 7xmeQ0LPUD5y for <lake@ietfa.amsl.com>; Tue, 25 Jan 2022 08:01:06 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD043A0D61 for <lake@ietf.org>; Tue, 25 Jan 2022 08:01:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E4BB3389D9; Tue, 25 Jan 2022 11:07:47 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id U_LzuRjCMrj7; Tue, 25 Jan 2022 11:07:45 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A5D6A389C3; Tue, 25 Jan 2022 11:07:45 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1643126865; bh=XpR5gWngilQd4D6SLpI24NcaOCP8KzVZqpZjhlp/R3M=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=AohhZ66/m6xgUPWbGS0AN5hpDCTz0cdlWizowPY9T+HrGVyyhKta7E8D4ZdO3ISvh aMkE8xWF+woHnTMh7IEZdzWRlZHBKmF4ZUKQZYrL2YmGsbInbTHrs7xr0zYxJLqWAc U9VRFgP2mM9U9wnTj9/G+rO35wVI7br8GHRS4QiSWHuPGQ15h5CXYwq4BPmSLRnHZS yWhYVIdC2xbWZtpFMeb6yMOZwCLk813X97upm8N2RFLDAKaW2E1kJDXKHwIG9a+N1a g1haL6VeHZ9bLoz9RZ/RkWD6e0s0fgBKaivuquPRgBmt4T+HLjtu9fKs6WH7QipPeF RfPaSLTCOoNEA==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 90FE22C1; Tue, 25 Jan 2022 11:01:00 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
cc: =?UTF-8?Q?G=c3=b6ran_Selander?= <goran.selander@ericsson.com>, "lake@ietf.org" <lake@ietf.org>
In-Reply-To: <f40de382-a46a-23ec-2228-82ae7d70faf3@cs.tcd.ie>
References: <2A2081E4-BAAF-4292-925E-0B683AA6CD23@inria.fr> <24192.1643036826@localhost> <AM4PR0701MB2195208CA41C14108E5CD85AF45E9@AM4PR0701MB2195.eurprd07.prod.outlook.com> <14667.1643068411@localhost> <f40de382-a46a-23ec-2228-82ae7d70faf3@cs.tcd.ie>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 25 Jan 2022 11:01:00 -0500
Message-ID: <12347.1643126460@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/V1T9_kWEbQw4Z-saixEwsgGeppc>
Subject: Re: [Lake] Ways forward on MTI cipher suite text
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2022 16:01:11 -0000

Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
    > On 24/01/2022 23:53, Michael Richardson wrote:
    >> (PS: I will have to check out of virtual interim early tomorrow)

    > Because of the above, I've a question...

    >> I don't agree with supporting (0*and* 1) or (2*and* 3) on a device.

    > I'm not clear if that means you can't *live with* the above, can you
    > clarify?

    > My reason to ask is that there are a plethora of reasonable positions
    > on this topic, so I'm not sure we'll land on one that everyone
    > likes. For me, that means maybe we're better to try find an imperfect
    > answer with which people can live, rather than try aim to make everyone
    > very happy.

I can probably live with almost anything, because RFCs are voluntary :-)

I think that if 0/2 is good enough, then don't do/support 1/3.
What's the point?
There is no security benefit, only coding errors and testing overhead.

If 0/2 is not good enough, then use 1/3.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email