[Lake] Fwd: Guidance on MTI algorithms in BCP 201 (was: Re: LAKE virtual interim: December 18th 2020, 1500-1700 UTC)

Rene Struik <rstruik.ext@gmail.com> Tue, 25 January 2022 16:41 UTC

Return-Path: <rstruik.ext@gmail.com>
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 0BB923A10DC for <lake@ietfa.amsl.com>; Tue, 25 Jan 2022 08:41:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TRACKER_ID=0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qni6QC6m4kmX for <lake@ietfa.amsl.com>; Tue, 25 Jan 2022 08:41:50 -0800 (PST)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56B4C3A10D6 for <lake@ietf.org>; Tue, 25 Jan 2022 08:41:50 -0800 (PST)
Received: by mail-qt1-x831.google.com with SMTP id k14so7947138qtq.10 for <lake@ietf.org>; Tue, 25 Jan 2022 08:41:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language :references:to:from:in-reply-to; bh=3pmoUSefUcHzzlZfqlcTv156jEhMPBvmITquD5eQAvU=; b=D0Xl3IiRnfNkc7yOkrgp902+nQ9UOiYFSWjcG4HJfOx0nJmDiJTbrJoK7e6yzAag43 38HFdgpRSYUD6vE2zfRaEiZLDpGLfzIXv2T0HlXF+SMNoWoScfleFZEF/kJr4SV4buXo VtEUqYcgH1i6ET51zY7N1CQBGUoBto2qHwiuFonevJ+k2mlUdEcbhQPAX5zpZ18yfen4 4XPoz62c5o8Csf0wOmbA60xxITpqu5WlUbZAGZF+1TV4FCEiSCY7xVM7VJKYZLrH+j3z wubxUsvteQNx2Usr3DRbHhdYzkAxfDD9K3ZbFB8ranqGYib1SX4VoPsQgE5V75zgOwVP 2BFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:references:to:from:in-reply-to; bh=3pmoUSefUcHzzlZfqlcTv156jEhMPBvmITquD5eQAvU=; b=ABOq7SA5IEFc9jmsWPWtNtTHb0SfWn0r8U3ULcYFqvcKnBtimHl9Ln1MrEyn9Guqny 8qtL/iZ1jINXuf62c3evVTfF3r0p9OudXOFPnjghnvMMNt0HCxad7lA8+z/vrGnFIRS1 gte8zFFmloKA/cT1X8aPYafNLvVImjxoY1E0tDaS6T9kLnXU/44Hx+tktqsLFeE8H+eS f6h+yhghh+UTIEJpzQDFy3gcbfdP7zHEHWOg0dXHW5Jg3vlAeEy19lf9okezOY56XNR0 EiDw269TnEXwQRaEFmY5OZl6bAihC1ZHUKgt+oKqxtcvYwWSg7dxkc9HPv1upLzmM8tH LVAg==
X-Gm-Message-State: AOAM531azCYsD0M3XSInlNAuAOL9g1IxY/a2kv56GZM7ihVEsrPS3ysS Ise3myhP+xE7uwWI0Mwm1w5d3n6bf6A=
X-Google-Smtp-Source: ABdhPJyYQZMX+z0i3uUgBwCMLbOX0Ndq4F6QnOUdQXavY+7BHoOl5Yqar7fNvwzT0ncrvYM/Aj0j2g==
X-Received: by 2002:a05:622a:3ca:: with SMTP id k10mr11138309qtx.506.1643128908305; Tue, 25 Jan 2022 08:41:48 -0800 (PST)
Received: from ?IPV6:2607:fea8:8a0:1397:c8e2:1d49:bb0b:1730? ([2607:fea8:8a0:1397:c8e2:1d49:bb0b:1730]) by smtp.gmail.com with ESMTPSA id q13sm8972543qtx.46.2022.01.25.08.41.47 for <lake@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Jan 2022 08:41:47 -0800 (PST)
Content-Type: multipart/alternative; boundary="------------ZW0IaTlzB7Srx0zreabvKNDX"
Message-ID: <56092327-b328-e9b1-95aa-ab3439c62eeb@gmail.com>
Date: Tue, 25 Jan 2022 11:41:45 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
Content-Language: en-US
References: <67bc4dab-f8d0-3aa4-0960-e9722c55156f@gmail.com>
To: "lake@ietf.org" <lake@ietf.org>
From: Rene Struik <rstruik.ext@gmail.com>
In-Reply-To: <67bc4dab-f8d0-3aa4-0960-e9722c55156f@gmail.com>
X-Forwarded-Message-Id: <67bc4dab-f8d0-3aa4-0960-e9722c55156f@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/3DozmrM6a_K-USBDWz7eCW8933Y>
Subject: [Lake] Fwd: Guidance on MTI algorithms in BCP 201 (was: Re: LAKE virtual interim: December 18th 2020, 1500-1700 UTC)
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:41:55 -0000

A simple reminder of what BCP 201 writes about MTI algorithms (as worded 
in my email of 13 months ago, on Dec 18, 2020).

Weblink to this email: 
https://mailarchive.ietf.org/arch/msg/lake/_sy7LSHk8idGAV_408JQOafi6LQ/

-------- Forwarded Message --------
Subject: 	Guidance on MTI algorithms in BCP 201 (was: Re: [Lake] LAKE 
virtual interim: December 18th 2020, 1500-1700 UTC)
Date: 	Fri, 18 Dec 2020 12:20:25 -0500
From: 	Rene Struik <rstruik.ext@gmail.com>
To: 	Mališa Vučinić <malisa.vucinic@inria.fr>, lake@ietf.org 
<lake@ietf.org>



Dear colleagues:

BCP 201 [1] provides some guidance on mandatory-to-implement algorithms 
(and discusses crypto agility as well).

Section 3.1 [2] discusses how to choose MTI algorithms, where these

(1) MUST have a stable public specification and public documentation that has been well studied, giving rise to significant confidence;
(2) The selected algorithms need to be resistant to side-channel attacks;
(3) It should also meet the performance, power, and code size requirements on a wide variety of platforms.
In addition, inclusion of too many alternatives may add complexity to algorithm selection or negotiation.  Specification of too many alternatives will likely hamper
interoperability and may hamper security as well.  When specifying new algorithms or suites, protocol designers would be prudent to consider whether existing ones
can be deprecated.

Section 3.2 [3] makes the case that too many choices may be harmful.

I believe this guidance may be useful in determining whether specific cipher suites would be suitable "candidate" MTI algorithms or would disqualify.

Best regards, Rene


Ref:
[1] BCP 201, RFC 7696 - Guidelines for Cryptographic Algorithm Agility 
and Selecting Mandatory-to-Implement Algorithms (November 2015). See 
https://tools.ietf.org/pdf/rfc7696.pdf
[2] https://tools.ietf.org/html/rfc7696#section-3.1
[3] https://tools.ietf.org/html/rfc7696#section-3.2


On 2020-12-18 5:25 a.m., Mališa Vučinić wrote:
>
> Hi all,
>
> As a reminder, we will be holding our virtual interim today at 1500 
> UTC for two hours. The materials for the meeting are available in the 
> datatracker [1]. In preparation for the meeting, I also invite you to 
> go through the github issues [2]. Webex connection details are below.
>
> We are also looking for a note taker, please do volunteer by replying 
> to the chairs.
>
> Thanks and talk to you in 4 hours and 35 minutes!
>
> Mališa
>
> [1] https://datatracker.ietf.org/meeting/interim-2020-lake-04/session/lake
>
> [2] https://github.com/lake-wg/edhoc/issues
>
> *From: *Lake <lake-bounces@ietf.org> on behalf of Mališa Vučinić 
> <malisa.vucinic@inria.fr>
> *Date: *Tuesday 1 December 2020 at 19:20
> *To: *"lake@ietf.org" <lake@ietf.org>
> *Subject: *[Lake] LAKE virtual interim: December 18th 2020, 1500-1700 UTC
>
> Hi all,
>
> Since we, the chairs, were running late in scheduling the virtual 
> interim for mid-December and in order to honor the two-week notice of 
> the meeting, we decided to skip the usual poll and fix the date to:
>
> December 18^th 2020, 1500-1700 UTC.
>
> We wanted to prioritize holding the interim before the Christmas 
> holidays, as agreed during the IETF 109 meeting. We apologize for the 
> lack of poll this time and we hope that you will still be able to make 
> it. We will post the minutes and the recording, in case you may not be 
> able to attend, and also confirm any decision made during the meeting 
> on the mailing list.
>
> The main item on the agenda will be going through the remaining EDHOC 
> issues, which were not covered during the IETF 109 meeting. If you’d 
> like to request a slot to discuss a different topic, please send an 
> email to the chairs at lake-chairs@ietf.org by December 8^th .
>
> You will find the information to join the Webex session on the 18^th 
> below.
>
> ===============================================
>
> interim-2020-lake-04
>
> Hosted by LAKE WG
>
> https://ietf.webex.com/ietf/j.php?MTID=mcb0c53b04465bc99ed249b6454b29663
>
> Friday, Dec 18, 2020 10:00 am | 2 hours | (UTC-05:00) Eastern Time (US 
> & Canada)
>
> Meeting number: 178 780 8136
>
> Password: Ajr7wC4WKT7
>
> 08c33c178f624890802c707e48c8da81
>
> Join by video system
>
> Dial 1787808136@ietf.webex.com
>
> You can also dial 173.243.2.68 and enter your meeting number.
>
> Join by phone
>
> 1-650-479-3208 Call-in toll number (US/Canada)
>
> Access code: 178 780 8136
>
> -- Lake mailing list Lake@ietf.org 
> https://www.ietf.org/mailman/listinfo/lake
>
>

-- 
email:rstruik.ext@gmail.com  | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867