Re: [lamps] OID für KEM?

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Fri, 08 October 2021 18:57 UTC

Return-Path: <prvs=691527a907=uri@ll.mit.edu>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4D63A0DE2 for <spasm@ietfa.amsl.com>; Fri, 8 Oct 2021 11:57:33 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_NONE=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 0qcORgUF_dKv for <spasm@ietfa.amsl.com>; Fri, 8 Oct 2021 11:57:28 -0700 (PDT)
Received: from MX2.LL.MIT.EDU (mx2.ll.mit.edu [129.55.12.51]) (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 50ABE3A0DE0 for <spasm@ietf.org>; Fri, 8 Oct 2021 11:57:28 -0700 (PDT)
Received: from LLEX2019-1.mitll.ad.local (llex2019-1.llan.ll.mit.edu [172.25.4.123]) by MX2.LL.MIT.EDU (8.16.1.2/8.16.1.2) with ESMTPS id 198IvPAq045019 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 8 Oct 2021 14:57:26 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=d62Uc9XcpjcoJFWApVEfm2dhGggjcfbi/fbqv3w6IedumiwjpXlNFP/aa1+342wdXBzitGyXarR5214b28Asvl2AhceuVCYUZ2ao9aGVjndMCQrU1ZQfs44vfWwIJhWxYlS/WgBKbabBT5SLAsQ7LgPeX36vYi4M492IlufUETRl9h4IqzQoMF5tETtUV4JsXYchA+SjR0V/PUX/t2sgXCRc04AiPGKrlZLHCtBhUm396TqRqBGyH0dPEI3xUHEr/3CQOD5xTiyix6elrQc+0B/7gfLvZ6O9ceSgZIBi5ozqfFrSucnaiyh5TEIjNdC04iUVsa2dABjhY2R+/nbY6A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bYbSu4I9n7UCAdaog+4EeXgG+5Wkf1g9zwSiPCGhH2Y=; b=qhsimaouS9cIVMrZGkHs0pGvgpGBbV5X0QOgHJzoa0HejCcuxtb/Ypn6XkuTNnLZ984BuC/1jUBW4jBWFaMy+EGGpIHJdrDZ5/pQTTgqMYI9/mHXyMA9ryWCWLNguU/SCxshTynAjel/784TH6jdgYraa4wzcsLDW4zBzApB1L1OHC1dNQrcpo7hXPjDLYbQf7zMaEvgqTAMfZrBeby4RIipcCCuk+PfnfNtYH4thWF1dZ/oJY/zdkiePE6kVuGEtZYXfLDLhKvqZADtj9CkuNNpo4QJ6KZks+SpTi9G7putwSCG6SVL3bRdHT/ktYiP6wicdtbbjtgtXhqeY5LyZw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>, Russ Housley <housley@vigilsec.com>
CC: LAMPS WG <spasm@ietf.org>
Thread-Topic: [lamps] OID für KEM?
Thread-Index: AQHXvGRWhcj346/cM0CZhvsQ6ENjEavJUY4A///BIACAAEQIgIAAASkA///Y7YA=
Date: Fri, 08 Oct 2021 18:57:20 +0000
Message-ID: <9710DAC4-ABB2-41D7-8F4B-BDC55DE96F62@ll.mit.edu>
References: <5BA17D7A-F19D-474B-8DD8-8EB36A363818@ll.mit.edu> <C7F5365D-3B42-49CF-AA4F-E6974F071422@vigilsec.com> <FBE3CC86-6DEE-4955-9BA8-3FE2DDF35F4E@ll.mit.edu> <8A3163D9-EB86-487E-B0D4-75A39AB44797@vigilsec.com> <20211008171710.GU4103@kduck.mit.edu>
In-Reply-To: <20211008171710.GU4103@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.52.21080801
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=ll.mit.edu;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ee8746ae-a6ee-4cf5-ff83-08d98a8d749f
x-ms-traffictypediagnostic: BN1P110MB0819:
x-microsoft-antispam-prvs: <BN1P110MB0819EA89D1B1F3185D092BFE90B29@BN1P110MB0819.NAMP110.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: lj+StDNrLyY154FcTooSnYzHMSlX50JTzKYK64C9rpEihXJCeGDYUCS4jnPNbmeGe64+2tmYBYIXF2Lk2Ec1g1ZIGUiX1VrEE4rJZZQ7+kQOqfnBcE73Xm6jaj6jO+E7Tv7JJF8zkb9URVs14wNzLbDCqnhQGHrZpbfysaGF9Wv6YTPiuP9UyWnpQo+dkAoYRurEZZxGrX5gvS9VygXWw28W5aBrY+oC5snpe7vYNq2igz87P4dRPJjAH3in4pzrhb7R5kXK9ptAODBy5nkZlHuHvd4VGYuff1RFfTkJ5S61xwgGMkPC1c5so9Q3TKdpVZ9bmK2KNlwbgTPEmBzWMCACQ8lkbXUDEvgK50lu9HQAeEpiZ9Q9Yb5G0G47y9J5eLCc4cF2jJh78qdnZ6DUC2s6UuO6CDuOu9gQpACwIY1JyYn2tDEa4BlO2QcZLfqvqvKBEwCtOvLt5DQpBPKES/yZi5yIZnoqtXOcCaeQ2o+ePJbyhHgY1MQ3EZKr39HVTQyp2DUnKLj/XTj3SMoLYXAEhuIDGTdc22JxtqlR5U3vTyoTcD0UkNqam/t7rhvCV2ifpKBNCdYYKjO5MhEj5boDnP5gbb7y7rm97G6FFznubMP+v/KEj4XuW+Mi/pio1X7IqQBQqJM+qVG2k5uh9Pv7SO0sISJh8x2OjiQcEuUp9tqmUynIUm297g+CxUwruCfJ7aQAeKW79fXjfrVvCwIhGPTj9QvtsrEuymjBjttc3iFw4i+iWjaFKJW6y+i3
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN1P110MB0706.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(4326008)(38100700002)(498600001)(76116006)(33656002)(8936002)(66946007)(83380400001)(66446008)(6512007)(64756008)(66556008)(66476007)(71200400001)(186003)(99936003)(6486002)(6506007)(53546011)(122000001)(5660300002)(75432002)(2616005)(224303003)(110136005)(26005)(966005)(2906002)(86362001)(38070700005)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: tNkzMFfp5hH6o8513uZFyCncv/oUb9CZfLZtuQM4+Y6RZWP7Xd7uI3t2qfYqkMQ6obVHIE1XAYNXHeT0xzQ+oHB9gvYf3y4ldrU3x4PvJE0PMP6wJIyHNCJjdz68IxkCX+lBIYjoCRxMLJzI9otfI41/WBg7UtauoNm8/pav6wBROiBC74EjL4BvV3D1p2GCWOshOUYLwinxOaMBKh6+1tMTPyvxkoM7GWUUWOfIg8fOXWAyd6XhGEU75Z8ao0Bj61+3MPvF17cQ8YHTj4/AycSHI52cGVnH25CvWgwKyDOhwqantRBi/juDB5oSGorLWVx31KeZCt9v7dva64TEl1d7jFUAoaNBaff3n5lNJmFyR/SpJghyYW8JwrF0rKTHTLDokVHNg1NVZB+Z7aBJxJxi7CMqruxawUlsSel5A78G5kjVE1n04aAYNFhVuqji/6Slxi/4ltv75CI9L7z7Abe68zrClKyUD024ESZrkMrslSyU/nXis38PQPfn/rcNwcCU/JVvKg4k4oV69cnSx/GvSnm6pBRFQ/M3oiMxwDbgWnha0sOReSYsqnTPMiJLc1noOBaX0QshEz2yLDEez4W+disZfH/s5v2YQNliIBuAFi7JfC5pinoeJN7p0KufVMlXDUc4suzjNhB/qD44u4/u1Heg7D0H3s2i9LKJtLiDlUGZxqTaMZcx+RfxtG3w/nkky1Oe3vQMXXNve5qrEA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3716549839_1927390425"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN1P110MB0706.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: ee8746ae-a6ee-4cf5-ff83-08d98a8d749f
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2021 18:57:20.0350 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1P110MB0819
X-Proofpoint-GUID: IuKUBehRM1CB5E9AX43U4GRdys9deG05
X-Proofpoint-ORIG-GUID: IuKUBehRM1CB5E9AX43U4GRdys9deG05
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-10-08_06:2021-10-07, 2021-10-08 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0 spamscore=0 bulkscore=0 malwarescore=0 adultscore=0 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110080106
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/BxoL2dHOA5zSsNo1hhu19xnVUfg>
Subject: Re: [lamps] OID für KEM?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Oct 2021 18:57:33 -0000

On 10/8/21, 13:17, "Benjamin Kaduk" <kaduk@mit.edu> wrote:
 On Fri, Oct 08, 2021 at 01:13:01PM -0400, Russ Housley wrote:
>> .  .  .  .  .  My worry is with the winning algorithms. 
>> I worry that implementations will have to support the
>> researcher-assigned OID and the NIST-assigned OID.
>
> Sounds like what happened at https://github.com/openssl/openssl/pull/16594
>
> OpenSSL waited for the final SHA3 to implement, but then
> got asked to also expose pre-standardization Keccak.
               ^^^^

I acknowledge the concern that Russ expressed. But IMHO, it's inconvenient at worst. I see no reason to bend over backwards trying to avoid such a situation.

Another example: NIST standardized AES, removing certain capabilities of Rijndael. In our use case (that predates SHA3 by almost a decade ;), we needed a 256-bit block cipher for crypto hash. So, in our protocol we had to use *both* AES (aka, modified/constrained Rijndael) *and* Rijndael itself. 
Since it was for "internal consumption", we got by with assigning no specific per-algorithm identifiers (agility was provided by another way, details would only bore the audience ;).