Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532C63A08ED for ; Thu, 27 Feb 2020 02:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 etK0kPSkpZk5 for ; Thu, 27 Feb 2020 02:47:14 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16EF53A086F for ; Thu, 27 Feb 2020 02:47:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.70,491,1574118000"; d="scan'208,217";a="340588647" Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.13]) ([82.64.165.115]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2020 11:47:10 +0100 From: Benjamin Beurdouche Message-Id: <4AEB16AA-BF20-4238-9B6E-2C0BD7760AC2@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_FF65B8DD-9134-4D69-90AA-907DC6AF678B" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Thu, 27 Feb 2020 11:47:10 +0100 In-Reply-To: Cc: Cas Cremers , Karthikeyan Bhargavan , ML Messaging Layer Security , Konrad Kohbrok To: Britta Hale References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> <619cf3d1-eb09-485c-595f-3bfbb4b175b5@gmail.com> <463B50F6-67FF-4E40-8CAE-14D272CDD965@inria.fr> <5A69070B-BF2F-4A91-939F-0BD473F3FB0A@inria.fr> X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [MLS] confirming cipher suites decisions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 10:47:25 -0000 --Apple-Mail=_FF65B8DD-9134-4D69-90AA-907DC6AF678B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Britta, > On 27 Feb 2020, at 10:57, Hale, Britta (CIV) = wrote: >=20 > Benjamin, > =20 > The issues you describe are primarily TLS-type problems, where = uncontrolled, large-scale agility and interop issues exist. Yes exactly, and I think two-party short lived connections for TLS are = easier to handle than will be the long-lived multi-party connections of MLS. > As has been stated in the working group as a supporting argument to = many changes over the different drafts, within the messaging/MLS space = we are looking at significantly more client-specific control. Yes, and we keep being careful that it is the case when writing the = drafts, but this doesn=E2=80=99t mean that we should be willing to risk = interoperability. > It is not unreasonable for a newcomer to support a selection of = signature schemes. If the group creator really wants full interop, they = can always define the set of available schemes to consist only of the = MTI. I think at reverse, if you are willing to break interop, you should be = selecting something else than the MTI when creating the group. And again, in what I say, = nothing prevents you to pick the NIST ciphersuite for compliance and use only that. But I don=E2=80=99t see the interest of mixing algs and put at risk = implementations and interoperability. Out of curiosity, where you somehow arguing for multiple MTIs here ? B.= --Apple-Mail=_FF65B8DD-9134-4D69-90AA-907DC6AF678B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Britta,

On 27 Feb 2020, at 10:57, Hale, Britta (CIV) = <britta.hale@nps.edu> wrote:

Benjamin,
 
The issues you describe are primarily TLS-type problems, = where uncontrolled, large-scale agility and interop issues exist. =

Yes = exactly, and I think two-party short lived connections for TLS are = easier to handle
than will be the long-lived multi-party = connections of MLS.

As has been stated in the = working group as a supporting argument to many changes over the = different drafts, within the messaging/MLS space we are looking at = significantly more client-specific control. =

Yes, and = we keep being careful that it is the case when writing the = drafts,
but this doesn=E2=80=99t mean that we should be = willing to risk interoperability.

It is not unreasonable for = a newcomer to support a selection of signature schemes. If the group = creator really wants full interop, they can always define the set of = available schemes to consist only of the = MTI.

I think at = reverse, if you are willing to break interop, you should be selecting = something
else than the MTI when creating the group. And = again, in what I say, nothing prevents
you to pick the NIST = ciphersuite for compliance and use only that.
But I = don=E2=80=99t see the interest of mixing algs and put at risk = implementations and interoperability.

Out of curiosity, where you somehow arguing for = multiple MTIs here ?

B.
= --Apple-Mail=_FF65B8DD-9134-4D69-90AA-907DC6AF678B--