IETF Logo Mail Archive

Re: [lamps] [EXTERNAL] Re: Security Consideration for draft-turner-lamps-nist-pqc-kem-certificates

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Fri, 25 March 2022 14:40 UTC

Return-Path: <prvs=1083d2975a=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 DC2033A0FFD for <spasm@ietfa.amsl.com>; Fri, 25 Mar 2022 07:40:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 kpc7L5hHdWLM for <spasm@ietfa.amsl.com>; Fri, 25 Mar 2022 07:40:46 -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 79A893A0CDA for <spasm@ietf.org>; Fri, 25 Mar 2022 07:40:31 -0700 (PDT)
Received: from LLEX2019-3.mitll.ad.local (llex2019-3.llan.ll.mit.edu [172.25.4.125]) by MX2.LL.MIT.EDU (8.16.1.2/8.16.1.2) with ESMTPS id 22PEeVW1436073 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 25 Mar 2022 10:40:31 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=GlcNJs5HYTPrJyO0AKGkdZpnHIxhIihnOQmlt2Y9T8NSuQtL3Gq67cxzIxoyqeVFrR04u0WmTXLZ9+fcMSafuiXeO0zDnYk32HNLOjkH1hWJ65IeDs0j54pHCCp5vbDM4+26Vk+axJihcJpGbVfycCnW1V1vzDcKxo2lvmE5DYzAhhsTLT4LqBcp/REBT4wmprwkz/m573WOYoOiXkGSqgNFfFLu63Dtsxq/NkZKMmY3nsfr1GYbykUg5QBDDb08QqvuB7pwCp8knHAyTqMDWXIsk7nL0u9pdCoflz8Kc3Dc3xc2RjEdczYYE+fEGOUHxM8OapwuaxpV2NeSj1DCww==
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:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=og533+gRf9y+l9Cq55LWWLnQs0UvXiaagkN6nlrIDh4=; b=JthKEbhQu3qFaB2k/2E1Rbdd9cfocXLk210CNlgVDYbtnhTB7OdQjZCRlTte3zfKBsN5yAEl8sPQLDu4dgBucI6zKoC4AUV1v+WAPe3wZIridXUpMfsHipxPdO3HEjrFK/h7UtBAyJEWEuREOAQDDUhvXpfTe3a/6P0pLTK3wsuJuVR321FCvO08W2nk7y/+1FCDyxP0D4at5dGzE79EL0bP46QE0f98zH2l+r7F+IPSjomiQ9iJK6pUESl7x20MksVjcJ2n9MC4WAZmKBX+e5r3Dg3+sX71tVSoC+CNmd678eTQPwnBYg4N0Tq0YAamUrona5L/ccLZlig8UDM1QQ==
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: Ilari Liusvaara <ilariliusvaara@welho.com>, LAMPS <spasm@ietf.org>
Thread-Topic: [lamps] [EXTERNAL] Re: Security Consideration for draft-turner-lamps-nist-pqc-kem-certificates
Thread-Index: AQHYQEyo8K0tmEpyyE6bsCxeF/uu0qzQHcQA///KyQA=
Date: Fri, 25 Mar 2022 14:39:17 +0000
Message-ID: <B9BA6885-4AF4-4BC0-9280-C39DB569603E@ll.mit.edu>
References: <CH0PR11MB5739B640691C4692D6343E219F1A9@CH0PR11MB5739.namprd11.prod.outlook.com> <LO0P123MB404186BF69C1FCC6275E7560D71A9@LO0P123MB4041.GBRP123.PROD.OUTLOOK.COM> <CH0PR11MB5739C9106FBE6D82E6B1EC1D9F1A9@CH0PR11MB5739.namprd11.prod.outlook.com> <19CA2384-E8A9-4E8F-9AA7-F8175393F065@gmail.com> <CH0PR11MB5739FFCC0723B521224BE9C59F1A9@CH0PR11MB5739.namprd11.prod.outlook.com> <Yj3IeJaGWX02kBk4@LK-Perkele-VII2.locald>
In-Reply-To: <Yj3IeJaGWX02kBk4@LK-Perkele-VII2.locald>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.58.22021501
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1cba8286-b254-4a0e-9464-08da0e6d3dd7
x-ms-traffictypediagnostic: BN0P110MB1627:EE_
x-microsoft-antispam-prvs: <BN0P110MB16271F3F2D6184D622A53B72901A9@BN0P110MB1627.NAMP110.PROD.OUTLOOK.COM>
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: nO6mi0oXv2NDEEoZp7keYK+sIYM8Xm7sdi65dmLOnJdQr2BHRL2hOAKDnmypHTc7gs+dMHBB8qyjkmONpErsL1ms4zjt3cCVlXd7XkseT9GHB325gnKuVTnaWXOlU1vP8k2Z5OO0plubRNtd40Fpke1XsDuepCtU3LHYT00/2OkgdwwCG97Oozv+3hEK0QjyRT0JpR4I4+vz0ERfb902Cfy/mhGmhk4QfUzGdYNzZwPlUnEuiACadYfuxigO8veRzDjBGsR7MH46Dk4GGGlfwHRnOxXuD67osWpbonFC7pFS6/f/3wu6LBWsLOfaAoQ0fQw+3tfrtpk6MPA6Pp4eBnhNtHDnknX8QNKSFE3MixEmFaax1PMByuaO3VQjrAjJiL4ENGVXCwUjfP+wzhrrcvn2+ZDBKcJSdFd+r3gv7jqnDNwC4aoMkvA9lGXbKXyeqLrD3rrpD3ZMRGqVjoveYvqxyE/R08z2Oglk69fZtsUH5SqremomalxW3+ortin0UHyA2w/dMHl1deBStW+YL5sckYG2F7sSsnULPwVPAK0XHsryir5Zhy3KrrxJdrdbS14DbhIJuIAoS7nZzuPnZxdp6qshk4Z4UippSmNV9YWdk1AXCc2YKb8OY/AHbbt2wPbzGKdwZUwEe933Lby+jFfJT0B0r6+aXG15ERYV0DOnFwp27XVwhGnl+CzkQ/6x5URf2/6arx/4BjnFLFDfVJafPyPdUac6LOiCLTLYF1BAc8rNrhAcU26LF3p7+3Ytsnx4L18DVvZ8imv1p/AV+w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(366004)(64756008)(66446008)(66476007)(76116006)(66946007)(66556008)(5660300002)(99936003)(38100700002)(6486002)(966005)(83380400001)(86362001)(508600001)(122000001)(186003)(26005)(8936002)(71200400001)(33656002)(110136005)(6512007)(8676002)(316002)(15650500001)(6506007)(75432002)(2616005)(2906002)(38070700005)(11970500015)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: WalIRU8Oy/tiRNEK4CQ3tbw8K+lAThua+DJw4mMt4BX+outA6JCAZEm0ZsFgk5uT0p+7YscMKVe4E9C79Aul59y2Txuzro65HX3wXG+xABLypSWJpGRHMzz92HDHKNR3yuuP+Wa2cEo9jeAHG28b8A==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3731049556_669286138"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 1cba8286-b254-4a0e-9464-08da0e6d3dd7
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2022 14:39:17.7015 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0P110MB1627
X-Proofpoint-GUID: 1175pZ8NV5vFztv_UiCE9cqx86-aNVEO
X-Proofpoint-ORIG-GUID: 1175pZ8NV5vFztv_UiCE9cqx86-aNVEO
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.850 definitions=2022-03-25_04:2022-03-24, 2022-03-25 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxscore=0 spamscore=0 adultscore=0 malwarescore=0 bulkscore=0 suspectscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203250081
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/bCvPSU0hGHNhYmpQMr-2f21SEkA>
Subject: Re: [lamps] [EXTERNAL] Re: Security Consideration for draft-turner-lamps-nist-pqc-kem-certificates
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, 25 Mar 2022 14:40:58 -0000

In general, I agree with the points Ilari made. However…

 
I think it’s good to allow SS of variable length;
When you allow variable length, you must include the length field into the hash;
I don't think padding is necessary in this case;
We should be careful regarding “max possible SS length”: while I don’t expect to ever see SS of, e.g., 56MB - I doubt it would stay at 32 or 48 bytes forever. I definitely don’t want to see “max possible SS len = 32”.
 

What’s the purpose of padding, if you included the length?

 

Re. RACOON attack – besides being pretty darn difficult to launch, it’s rather limited in applicability, IMHO – to the point I don’t really care. Besides, offhand, it isn’t applicable to NIST KEMs.

 

Thanks

-- 

V/R,

Uri

 

 

On 3/25/22, 09:50, "Spasm on behalf of Ilari Liusvaara" <spasm-bounces@ietf.org on behalf of ilariliusvaara@welho.com> wrote:

 

    On Fri, Mar 25, 2022 at 01:30:28PM +0000, Mike Ounsworth wrote:

    > > So if your scenario envisions concatenating a traditional

    > (RSA/FFDH/ECC) shared secret and a PQ shared secret, one would want

    > to be sure the first component of the concatenation is not variable

    > length.

    > 

    > Another good point!

    > 

    > Thinking out loud: does padding solve the problem?

    > 

    > H(ss_1 || ss_2 || .. || ss_n)

    > 

    > if ss_i are each padded / truncated to, say, the security level of

    > the underlying hash function, does that work?

 

    One could solve the issue for variable length SS by adding a length

    field and padding to the maximum possible SS length. I think truncating

    is a bad idea, and could interact badly with some oddball KEMs.

 

    However, using KEMs with variable-length SS seems like a bad idea

    anyway. E.g., see the TLS RACCOON attack.

 

 

    -Ilari

 

    _______________________________________________

    Spasm mailing list

    Spasm@ietf.org

    https://www.ietf.org/mailman/listinfo/spasm

v2.40.3 | Report a Bug | By Email | System Status