IETF Logo Mail Archive

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

Carsten Bormann <cabo@tzi.org> Tue, 25 January 2022 00:34 UTC

Return-Path: <cabo@tzi.org>
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 D97FD3A19DB for <lake@ietfa.amsl.com>; Mon, 24 Jan 2022 16:34:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 3BAcjRtHIl0c for <lake@ietfa.amsl.com>; Mon, 24 Jan 2022 16:34:43 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 839913A19D9 for <lake@ietf.org>; Mon, 24 Jan 2022 16:34:42 -0800 (PST)
Received: from smtpclient.apple (p5089a6b7.dip0.t-ipconnect.de [80.137.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JjSXs4SSVzDCbL; Tue, 25 Jan 2022 01:34:37 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <f40de382-a46a-23ec-2228-82ae7d70faf3@cs.tcd.ie>
Date: Tue, 25 Jan 2022 01:34:36 +0100
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "Apple Inc." <goran.selander@ericsson.com>, "lake@ietf.org" <lake@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7156A5F1-E6E8-45B2-9109-B70C1AE32EF8@tzi.org>
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>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.3693.40.0.1.81)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/GzYkdsMViAFJDQOfnNg2DKbCNc0>
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 00:34:48 -0000

On 25. Jan 2022, at 01:16, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 
> you can't *live with*

I should probably say that I can’t live with an RFC 6919 “MUST (BUT WE KNOW YOU WON'T)”.

We need to be realistic in our mandates.

"At least one out of 0..3" would be realistic.

(The value of an MTI for a component that goes into other standards before becoming a product is also limited — The MTIs in this case should be in the system standards, not in the component.)

Grüße, Carsten

v2.23.0 | Report a Bug | By Email