Re: [MLS] confirming cipher suites decisions

"Hale, Britta (CIV)" <britta.hale@nps.edu> Thu, 27 February 2020 09:58 UTC

Return-Path: <britta.hale@nps.edu>
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 4FFB13A16EE for <mls@ietfa.amsl.com>; Thu, 27 Feb 2020 01:58:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 g-237tR4uY3b for <mls@ietfa.amsl.com>; Thu, 27 Feb 2020 01:57:59 -0800 (PST)
Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 592423A16E9 for <mls@ietf.org>; Thu, 27 Feb 2020 01:57:59 -0800 (PST)
X-ASG-Debug-ID: 1582797478-0e39454964c8890001-bGA3T6
Received: from mail.nps.edu (synergos.ern.nps.edu [172.20.4.116]) by mule.nps.edu with ESMTP id trw7D6ANEMjFr5j6; Thu, 27 Feb 2020 01:57:58 -0800 (PST)
X-Barracuda-Envelope-From: britta.hale@nps.edu
Received: from skywalker.ern.nps.edu (172.20.4.117) by synergos.ern.nps.edu (172.20.4.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Thu, 27 Feb 2020 01:57:58 -0800
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.172) by skywalker.ern.nps.edu (172.20.4.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3 via Frontend Transport; Thu, 27 Feb 2020 01:57:58 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FU06tPi9EnGNAdVRn9dE32wpCpdJLXa5eCqwg/ZqzwnIxXgxtg9BNbjsjla/kEIoO+IrJkZKvvnq2ISKmlNqRC48wWqJUeP84d2QYWPqHlt//5FK8B2jc7vnzTpwM8Y0rj7SOCQdfyG75VDQODVyqqTaZYDF36f1JbG/Ohg8iM62QDTx5gURWmA88QkT3d9KNi36NHSYYY+cBeDl9MdgYVdhCsY25qmZtS839By1JyM2bSTV7/o0eV09wuUkwP8gO57kCbrpSnrKMnhOUKeQcg3vQGhl4cUOXmwVGSIaQ8rcukWDUJUSzkKtTkF8KsYFsBYA64Rl32Xh7VaY26KG0A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=96gJp0MulT95Z+AIpZ9PU7EG4IECcm/xry3S7boDqWQ=; b=T/TLTy+AgmNtxB4dd91hDzWVy9X2D9iB9LkbenK56zsNa+QDYlOBBqUnsCHmTnp+hYeJ2ZQwHz2FGoGa9MV4DymTkvD1HqGpWvduYkJHpUaBwKpiibpPFJDv8bUNRWQ2OTgXr36mO1pk6FF5UMpn8IibdSfVKFwd6fsmaz97JnM6V2SkGm2ZfbnbviEmtSEFXbJaHzu+XIb3UDcuN/kYl/H3r02mMeYenhA2ZuqjGdsQcr/ivjmu072CyJoRp9JYlYtqt/AkMOsvGJh+zSqse3UOIMSogHdu0xsp7I5PrvGMCO7aBHUnBadWbiBiKjzJqP5ssmCPaFf55X3F+EnZQg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nps.edu; dmarc=pass action=none header.from=nps.edu; dkim=pass header.d=nps.edu; arc=none
Received: from BY5PR13MB3013.namprd13.prod.outlook.com (2603:10b6:a03:185::31) by BY5PR13MB3315.namprd13.prod.outlook.com (2603:10b6:a03:1a1::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.5; Thu, 27 Feb 2020 09:57:54 +0000
Received: from BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::31ba:c240:895e:1475]) by BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::31ba:c240:895e:1475%7]) with mapi id 15.20.2772.012; Thu, 27 Feb 2020 09:57:54 +0000
X-Barracuda-Effective-Source-IP: UNKNOWN[2603:10b6:a03:1a1::28]
X-Barracuda-Apparent-Source-IP: 2603:10b6:a03:1a1::28
From: "Hale, Britta (CIV)" <britta.hale@nps.edu>
To: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>, Cas Cremers <cas.cremers@gmail.com>, Karthik Bhargavan <karthikeyan.bhargavan@inria.fr>
CC: ML Messaging Layer Security <mls@ietf.org>, Konrad Kohbrok <konrad.kohbrok@datashrine.de>
Thread-Topic: [MLS] confirming cipher suites decisions
X-ASG-Orig-Subj: Re: [MLS] confirming cipher suites decisions
Thread-Index: AQHV3QgItlQOeVhVQUSdKiw0YIWW2agXOr8AgAmxSwCAATAYgIAKMACAgAALVYCAAXH8AIAAIHiAgAAGs4CAAA3FAIAA4SKA//+JDYA=
Date: Thu, 27 Feb 2020 09:57:54 +0000
Message-ID: <A6881857-406E-45E9-BEC7-823E15633619@nps.edu>
References: <D107086A-ED6C-48D8-8BC3-B3AE7E424F85@sn3rd.com> <D2B8EAF9-9109-4247-B714-13306724F712@nps.edu> <B02410C5-F6C3-4580-AA92-C48687731919@nps.edu> <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <CAL02cgS813EWDm8g=_P18XHVJJJErgit4OWP7fDCMPzkQcJQQw@mail.gmail.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>
In-Reply-To: <5A69070B-BF2F-4A91-939F-0BD473F3FB0A@inria.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.12.200112
authentication-results: spf=none (sender IP is ) smtp.mailfrom=britta.hale@nps.edu;
x-originating-ip: [195.158.89.246]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: de3b5b02-8ee3-483d-422d-08d7bb6b8414
x-ms-traffictypediagnostic: BY5PR13MB3315:
x-microsoft-antispam-prvs: <BY5PR13MB331532071D8FFB7308026821FBEB0@BY5PR13MB3315.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 03264AEA72
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39840400004)(396003)(366004)(346002)(376002)(136003)(189003)(199004)(66946007)(76116006)(71200400001)(8936002)(8676002)(81166006)(81156014)(75432002)(5660300002)(4326008)(91956017)(2906002)(66476007)(6506007)(53546011)(478600001)(786003)(36756003)(316002)(54906003)(64756008)(966005)(66446008)(66556008)(86362001)(110136005)(6486002)(26005)(33656002)(6512007)(2616005)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR13MB3315; H:BY5PR13MB3013.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nps.edu does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: W5+YrZ2f3oqVUN0GJV/JxIhisPoUP+903YFc4sBtrikE6aoPM1/pVbRsDM3J1NqpCrtrzQRDk7g+hQv9lC1eGwJK9WFCaISn6cUIzpqtyxkukN+IUkD4uvqWwwTygyEL+H9KU0/x2WNCPp7ZLa6VjVYDu1g5Zu3SrirvLdbiK6p7O+K/lQWxGJfS+4ng4yHTSelhyDje80t7zac5h1gsGNo0YYUz4oapCU97QacIRCSj7kiCIy/BTXbBxnCVxsGS04GGfzcg9y9tu3sh/pGKmQmYwiDyKPZOPMsqtzcMGjMg5UoXL3tH7pM0EoY2Tbwl57cRHY0bz18amn9ILffp9i+watb/QFt/YTvSxbxCUC8mXn1HFrzkFv3OApX/kMwF0i1Xz7HkTn8Bl5IfJhRQzANXv588lgwaTEn+cjbssRl4P+U27nOyDsRBpEzFs0TBQXis6e1L6/HibfKCbessDRcdxYd8roZHl5XyCLIYuv3ZZ69rlpnozm1PSC9aP6/qyXXIw7t5QZqfurxg0hOkiQ==
x-ms-exchange-antispam-messagedata: 53tn4/87w5q9VA6BiJtlBjuqFqDA8ITZJvWJl65q3NoKooFT6EBao3hXGBf6oqPe5NCiK09sRI/2zoBLKF/bnibhwRMlzV9HieRtLITTyHHlg+sL239KrBTeK+IduaixUE+WL1HzKG/RcO1lFGClCg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_A6881857406E45E9BEC7823E15633619npsedu_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: de3b5b02-8ee3-483d-422d-08d7bb6b8414
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2020 09:57:54.6770 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6d936231-a517-40ea-9199-f7578963378e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: lmhbdphQ+Yi5eYrRFxCkgkuSyIZuWugXI6OIFCMfoNJWPCaXNJHq3l6lJ+A9EtlQscEeIAIjAWsZr5QX22AXdQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3315
X-OriginatorOrg: nps.edu
X-Barracuda-Connect: synergos.ern.nps.edu[172.20.4.116]
X-Barracuda-Start-Time: 1582797478
X-Barracuda-URL: https://205.155.65.106:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at nps.edu
X-Barracuda-Scan-Msg-Size: 15154
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.80292 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/OtG0Z01nF1nYzVVlbt1xKBrWOvM>
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 <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2020 09:58:06 -0000

Benjamin,

The issues you describe are primarily TLS-type problems, where uncontrolled, large-scale agility and interop issues exist. 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. 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.


Britta




From: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Date: Thursday, February 27, 2020 at 10:03 AM
To: Cas Cremers <cas.cremers@gmail.com>om>, "Hale, Britta (CIV)" <britta.hale@nps.edu>du>, Konrad Kohbrok <konrad.kohbrok@datashrine.de>
Cc: Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>fr>, ML Messaging Layer Security <mls@ietf.org>
Subject: Re: [MLS] confirming cipher suites decisions

From the last messages, I think my answer to Cas was misleading…

R1. Joining a group without supporting all the crypto is unacceptable
R2. Allowing a system where clients all advertise the MTI ciphersuite
and where the newcomers cannot join should be unacceptable.

Goal of MLS: we want everybody to be able to build a group and talk securely
to everybody else. No need for security if people can’t create groups because of
algorithm fragmentation.

On 26 Feb 2020, at 20:37, Karthik Bhargavan <karthikeyan.bhargavan@inria.fr<mailto:karthikeyan.bhargavan@inria.fr>> wrote:

Hello All,

I think we could go either way: multiple or single signature algorithm per group.
However, I would prefer if we required *all* the algorithms that group members must support to be declared up-front at group creation.

This is currently the case that “that all the algorithm that group members must support
to be declared at group creation" and it is also the root cause of potential fragmentation.

If the creator takes the responsibility of explicitly picking something else than the MTI ciphersuite
they take the risk explicitly to break interop and break R2, but that is fine.

If we went for the scheme such as picking a list which contains more than the MTI, even at
group creation, *only clients supporting everything* would be allowed to join otherwise breaking R1.

To me this Is unacceptable.
That is why we want to restrict this set to a minimum: in my case to *one* ciphersuite.
The largest set the creator will pick, the more difficult it will be for new member to join the group.

That is, my preference is not to add new signature algorithms as a group evolves and new members are added.

That was never an option.


The rationale behind this thinking is that when a member joins a group, she can inspect the group’s parameters to decide whether she supports
the algorithms needed to converse in the group. It would be weird if the group allowed a new member whose authentication credential or message signatures
cannot be processed by existing members.

If the newcomer doesn’t support enough, but just the MTI, they may never join which is
unacceptable, as everyone else has to support the MTI, R2.

And it would be hard to try to dynamically detect the algorithms that the group members support.
Instead, declaring all *required* algorithms at group creation seems like a sane choice to me.

So again, requiring to support more, is not only a dangerous idea regarding implementations,
but is dangerous for interoperability and fragmentation.

Moreover this new proposal is not solving any of the current problems I have with the multiple
algorithms approach I had in my previous message:
-----

1. agility causes a lot of problems: I don’t think I need to remind people of the TLS story https://hal.inria.fr/hal-01114250

2. interop fragmentation: this is not a two party protocol where membership is set forever.
If a single member does not support one crypto scheme, this member might never be able to join an hybrid group.

3. security: I clearly don’t believe we should assume anything from the security of the protocol
in the case a cryptographic scheme is broken. I don’t want to get to a point where we have horrible downgrade stories
and I would clearly want to kill and restart the entire group

I think fragmentation is my main worry actually, and if we figure out that we were wrong,
adding more agility is likely to be more easy than removing it.

So my intuition is that we should proceed with one signature scheme for the lifetime of the group
and make sure we have a solid story to export and reconstruct a group, which we need anyway.

B.