Re: [lamps] AD review of draft-ietf-lamps-cmp-algorithms-07
Roman Danyliw <rdd@cert.org> Fri, 05 November 2021 12:32 UTC
Return-Path: <rdd@cert.org>
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 179CE3A0E88 for <spasm@ietfa.amsl.com>; Fri, 5 Nov 2021 05:32:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=seicmu.onmicrosoft.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 Dxe3Ou55VOV1 for <spasm@ietfa.amsl.com>; Fri, 5 Nov 2021 05:32:25 -0700 (PDT)
Received: from USG02-CY1-obe.outbound.protection.office365.us (mail-cy1usg02on0128.outbound.protection.office365.us [23.103.209.128]) (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 C3E723A0E8A for <spasm@ietf.org>; Fri, 5 Nov 2021 05:32:24 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=F/PeyZCHAtXdqUru0zQNDIQRarvhy13/izLiAaYs4P4HkVokoFqIklmtXtWRU7/4K5kvHGMOf4qusRPXHbDXibM9z2rmv6PAUAc3uz9F0iSJRHpE6oLpOWiGDsZ33Ysgm/V7WjJfbH57S6jNbnDksDlVLTr/J8qHtCh8hhQH1vyGXKnnZIFpwVPl5AxGOEW2ZQhG7uP73W3kLlkK5vdltiMBMx+tIcxWva0V5UAeKSHs9AAc8Zg7PlQLEJAF8/bv2nFuNL54s38J11UZtLEKezGYm8VUupwzmmLSTvEF4vsTHeYS3P9R8hNqs5Prfp6rnSSMuwdb4H3YExtKu5Q4kQ==
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=PD9LIq7Dnpw+WZbBxtLGJhfXfOi4IR2HUQOyusFBhGc=; b=BYHYVrlbN6CiB5Oz9iv6C35PMm3DvSZE6Wh39LtZRvArLr1RfBCJb9WX3p3gSTwYb0poJAIGuk1C8vufqwdRYBzBLR9sfyt0gYy0XERejRzcvkOiYuT6ehBZEkOYxunLMfmUMwnv1sySmbdaf6kpiGEmYwjzrQpa/uLHlkEzeS/FwTqMns0T52kqQRCS4f77uyvPcrZVuJ+tupOMKCsiO/VUcR1bFMUDGCC7nLS9Aisk2pYfklDko6nYHYhbAcH4wEaAbtr7454Bvd2XvB5YEx/8fi0z+qbWGgQ59nrHhu+jKWDxs5GVrcAT79n2gDy/7v6RzBJ5tLr3THL/k+Q8rw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cert.org; dmarc=pass action=none header.from=cert.org; dkim=pass header.d=cert.org; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seicmu.onmicrosoft.com; s=selector1-seicmu-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PD9LIq7Dnpw+WZbBxtLGJhfXfOi4IR2HUQOyusFBhGc=; b=EvWpSzxvyPrApOJMJJZKi7M+w5qWP3xc73/OkFQ/Qj4+LRVVsBoTxCV264TemVFt44Aw3pTb8Nc/WwqtHpvZU3l56WoJMvwWwAfABlYTTBXuUrUww6Jj+SYGpwzk6JOTN5MrtZ9RdsoPBHVApqpEz79TLVKpMvTV9X2/kyIBPR4=
Received: from BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:134::12) by BN1P110MB0865.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:133::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.16; Fri, 5 Nov 2021 12:32:08 +0000
Received: from BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM ([fe80::4463:48d1:9769:567f]) by BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM ([fe80::4463:48d1:9769:567f%6]) with mapi id 15.20.4649.017; Fri, 5 Nov 2021 12:32:08 +0000
From: Roman Danyliw <rdd@cert.org>
To: "Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com>
CC: LAMPS WG <spasm@ietf.org>
Thread-Topic: AD review of draft-ietf-lamps-cmp-algorithms-07
Thread-Index: AdfKsmHop5v82zipS+Kei9oAXI0KtQF6h4rQAGbB71A=
Date: Fri, 05 Nov 2021 12:32:08 +0000
Message-ID: <BN1P110MB09392B30E65D3D02F45ED706DC8E9@BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM>
References: <BN1P110MB0939774B07F1FF05E5DBBC42DC849@BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM> <AM0PR10MB2418AFBC3AA679C2371A3175FE8D9@AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM>
In-Reply-To: <AM0PR10MB2418AFBC3AA679C2371A3175FE8D9@AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2021-11-04T18:04:00Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=b683b9ed-ffa3-47d3-ad34-d6022fe05c47; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
authentication-results: siemens.com; dkim=none (message not signed) header.d=none;siemens.com; dmarc=none action=none header.from=cert.org;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: eaa62fb2-8d81-4694-1617-08d9a05848b1
x-ms-traffictypediagnostic: BN1P110MB0865:
x-microsoft-antispam-prvs: <BN1P110MB08657D596256DEB7086086D0DC8E9@BN1P110MB0865.NAMP110.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: R1Xei7xRQYT31pf8osAMdins+BtpRIUIptZQLRewOrklWIwM0mRZy+pDp2p4YMD62HNGDtz7eqkDB72pWCJRwbzK9+SZOWNjGwaY1FovR1N0bO8A/shGbbgSthHCJiV1WTkzbU/v1m2+B8iwKdShV2y34tmmpECGTsrp98aqU34kcwtqQaQyPKF1aJtB0w71xPnbzcD+bKcGEAX3+QciiyVITbwmog02ypsR6iElD6hn5jUASRE+VgkeeIDhIlb6z0BPJSGEHbhBZ6636hfjnvCELfKRem8MvFJcd7dd2beuCVqDRT+QQqeG6UCO+XFVXLnTawFyJxI8Hc1sttyA5UWa3LKYGfKq9xr5WG6W1kbER0DgkH79gpgBren3HBgx7YReH4K33epD5WF0rR/jGwyeZhIREQHeyv+rgLe8BAiuGqUWW6D/V0bONLf8hfqhKlElla+osoVPxxsNL+v6viqBDdJ5G2hy0fdABJKy9mwiqhT/8RgJ62/4HQ1tZqSpkdJwrtadcK3tKz7zFM8CJFhaPnv2WwS7m96rRFF7r5BxlSjW22m9tPV3SI8y/QHnDOCaRIoun7OHW+vZUhxtQFsX9RBsn7LdFU5WOFw4BsD6irggHyvUWXeRsJG4rn4l
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(71200400001)(26005)(86362001)(52536014)(498600001)(186003)(8936002)(8676002)(9686003)(33656002)(4326008)(53546011)(55016002)(7696005)(6916009)(2906002)(66946007)(66476007)(5660300002)(64756008)(66556008)(6506007)(66446008)(38100700002)(76116006)(30864003)(38070700005)(122000001)(83380400001)(82960400001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: Zd3wK9roSVqT3NWnx2KKB0gd1DPIyowkZmJ9Ha1kZt9iJ/gaGHanOx7Vr5Cz0epoq9AgJD0HTQqzCOt/jg+LUR2FrHZ3Ci7wDRuwt7khuJv8gTZ/zeaoNezgtV7JIugtgLGusMg/CiBaPllUaODGlHY2YmOYIKJ88ebpiOlovLeiDblFocqwvihtKIBmCMCSb+6KHdOCxU1Du/yb+PvB1kRAKgRocD/OFc3SaeSlOzMQzQCSoWktK0D9y2qaUO7BB1J0R1fGixdwFJlhzbn9pKswdHJSIcSDbr7jmNAUykkVXxiEO0qHmJcviAlSIJ9PBeS4dxSp5rXQUD4svY3EUQwpN+goycj25591QhDTyJ6qomVAL3AxuR0uKPi+DlBBkcl3X97GDzRvpXgJ9lPRD2qp7ALhEJkBrhHPRikhcO5unQnzSsK28U26DbvmhpJh3zdLYWuxMvLd8GLoQqcHeJKIW5XtI4GDodShWQTCABy16USo47x80+tokYx9c3tH4yshJIJE+f5n8OJwK8Iavhmd1Q+bpPKIkOAjQfw6rEORYtVMeot2JWgsLTQ1BgTjMh6vtOCcnZ3bn7kqRfL9k6V1eJEg8zSlE9EUk8EYjB02csSENNgcyAtb8Z/eJ3LJ1ZllYIco5wHGA5R0+qGTMS2or9OFOcWOo0YQVdGkuEAsb3C/ogOxEoVKFVP3wfhQgMx0uwkXKYt+g7L3MjAmAe/h5K1+kjwmisEtrUf2aTU=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: cert.org
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: eaa62fb2-8d81-4694-1617-08d9a05848b1
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2021 12:32:08.5457 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 95a9dce2-04f2-4043-995d-1ec3861911c6
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1P110MB0865
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/oBTDvtfjn7PjcxthHt7zITvEfqE>
Subject: Re: [lamps] AD review of draft-ietf-lamps-cmp-algorithms-07
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, 05 Nov 2021 12:32:30 -0000
Hi! > -----Original Message----- > From: Brockhaus, Hendrik <hendrik.brockhaus@siemens.com> > Sent: Thursday, November 4, 2021 2:04 PM > To: Roman Danyliw <rdd@cert.org> > Cc: LAMPS WG <spasm@ietf.org> > Subject: AW: AD review of draft-ietf-lamps-cmp-algorithms-07 > > Roman > > I aligned with Mike, John, and Hans. > Please see our feedback on your comments regarding Section 7 and Section 9 > below. > > > Von: Spasm <spasm-bounces@ietf.org> Im Auftrag von Roman Danyliw > > Gesendet: Dienstag, 26. Oktober 2021 23:49 > > > > Hi! > > > > I did an AD review of draft-ietf-lamps-cmp-algorithms-07 with my > > comments below. Thanks for this work to evolve CMP. > > > > ** Section 7. I would have benefit from a bit more clarity on the > > direction provided in this section. > > > > -- "The following criteria will help implementers choose appropriate > > algorithms for managing certificates" > > > > The bulleted list seems like only part of the criteria. As a > > non-exhaustive list, additional considerations might be the > > capabilities of the end-point (e.g., does the target deployment have > > hardware acceleration for some, are some algorithms simply out of > > reach due to available compute or expected software support); or perhaps > local policy or compliance requirements? > > > > -- "The cryptographic strength of the algorithm with the lowest security." > > > > It seems like some words are missing here. Is the intent here to > > guide the selection towards the algorithm that provides the minimum > > amount of strength relative to the needed security requirements? > > Thank you for this feedback. We propose the following changes. > In addition to that we think another table in the introduction of Section 7 > listing the different algorithms sorted by its security level (bits of security) > would help. We plan to present such a table during the LAMPS session for > further discussion. > > Old: > The following criteria will help implementers choose appropriate > algorithms for managing certificates: > > * The cryptographic strength of the algorithm with the lowest > security. > > Note: To avoid consuming too much computational resources it is > recommended to choose a set of algorithms offering roughly the > same level of security. > > * The entropy of the shared secret information or password when MAC- > based message protection is used, e.g., MSG_MAC_ALG. > > Finally, the cryptographic strength of the system SHOULD be at least > as strong as the algorithms and keys used for the certificate being > managed. > > New: > The overall cryptographic strength of a CMP deployment will depend on several > factors, including: > > * Algorithm profile: The overall strength of the profile will be the strength > of the weakest algorithm it contains. > > * Message protection: The overall strength of the CMC message protection > - MAC-based protection: The entropy of the shared secret information or > password when MAC-based message protection is used, e.g., > MSG_MAC_ALG. > - Signature-based protection: The strength of the key pair and signature > algorithm when signature-based protection is used, e.g., MSG_SIG_ALG > > * Certificates managed: Finally, the cryptographic strength of the system > SHOULD be at least as strong as the algorithms and keys used for the > certificate being managed. > > To avoid consuming too much computational resources it is recommended to > choose a set of algorithms offering roughly the same level of security. Below > are provided several algorithm profiles which are balanced, assuming the > implementor chooses MAC secrets and / or certificate profiles of at least > equivalent strength. Works for me. Thanks. > > > > ** Section 7.1. The text in this section seems it should explicit say > > that it is updating RFC4210. > > > > OLD > > The following table contains definitions of algorithms used within > > > > NEW > > The following table updates the definitions of algorithms used within > > I am fine with this change. Thanks. > > > > ** Section 7.1. If an algorithm is listed in the "Change from 4210" > > column, should it be considered the equivalent of being added to the > > "other" column (per Appendix D.2 of RFC4210? If so, please be explicit about > that. > > We will delete the column "Changes from 4210" and introduced two columns, > "Optional" and "Deprecated". "Deprecated" contains all algorithms define in > RFC 4210 Appendix D.2 which SHOLUD NOT be used any more. That's even a better. > > > > ** Section 7.1. Table 1. > > > > -- What does it mean for PasswordBasedMac to be in both the Mandatory > > and > > Change-from-4210 column for the MSG_MAC_ALG row? It was already the > > MTI in RFC4210. Same question and situation with D-H for the > PROT_ENC_ALG row. > > PBMAC1 became MANDATORY and PasswordBasedMac became OPTIONAL. > > > > > -- Should 3-DES be considered "other" in MSG_MAC_ALG and > PROT_SYM_ALG? > > 3-DES (3-key-EDE, CBC mode) became Deprecated as you proposed below. > > > > > -- Editorial. In PROT_SYM_ALG and SYM_PENC_ALG, the "3-DES > > (3-key-EDE), CBC Mode" should read "3-DES (3-key-EDE, CBC mode)" per the > text in RFC4210. > > Thanks for the clarification, we can fix this. > > This is the Update we propose for Section 7.1 Old > Change from 4210: Shows the changes in the Mandatory and Other > algorithms from RFC 4210 [RFC4210]. These are included for backwards > compatibility considerations. > > > +============+===============+==================+================== > =+ > |Name |Use | Mandatory |Change from 4210 | > > +============+===============+==================+================== > =+ > |MSG_SIG_ALG |protection of | RSA |DSA/SHA1 | > | |PKI messages | |Others: RSA/MD5, | > | |using signature| |ECDSA | > +------------+---------------+------------------+-------------------+ > |MSG_MAC_ALG |protection of | PasswordBasedMac |PasswordBasedMac > | > | |PKI messages | (RECOMMENDED: |Others: HMAC, X9.9 | > | |using MACing | PBMAC1) | | > +------------+---------------+------------------+-------------------+ > |SYM_PENC_ALG|symmetric | AES-wrap |3-DES(3-key-EDE), | > | |encryption of | |CBC Mode | > | |an end entity's| |Others: AES, RC5, | > | |private key | |CAST-128 | > | |where symmetric| | | > | |key is | | | > | |distributed | | | > | |out-of-band | | | > +------------+---------------+------------------+-------------------+ > |PROT_ENC_ALG|asymmetric | D-H |D-H | > | |algorithm used | |Others: RSA, ECDH | > | |for encryption | | | > | |of (symmetric | | | > | |keys for | | | > | |encryption of) | | | > | |private keys | | | > | |transported in | | | > | |PKIMessages | | | > +------------+---------------+------------------+-------------------+ > |PROT_SYM_ALG|symmetric | AES-CBC |3-DES(3-key-EDE), | > | |encryption | |CBC Mode | > | |algorithm used | |Others: AES, RC5, | > | |for encryption | |CAST-128 | > | |of private key | | | > | |bits (a key of | | | > | |this type is | | | > | |encrypted using| | | > | |PROT_ENC_ALG) | | | > +------------+---------------+------------------+-------------------+ > > New > Optional: Algorithms which are OPTIONAL to support > > Deprecated: Algorithms from RFC 4210 [RFC4210] which SHOULD NOT be used > anymore > > +============+===============+==========+=================+======== > ===== > ++ > |Name |Use |Mandatory |Optional |Deprecated | > +============+===============+==========+=================+======== > ===== > ++ > |MSG_SIG_ALG |protection of |RSA |ECDSA, EdDSA |combinations | > | |PKI messages | | |with MD5 and | > | |using signature| | |SHA1 | > +------------+---------------+----------+-----------------+-------------+ > |MSG_MAC_ALG |protection of |PBMAC1 |PasswordBasedMac,| | > | |PKI messages | |HMAC, X9.9 | | > | |using MACing | | | | > +------------+---------------+----------+-----------------+-------------+ > |SYM_PENC_ALG|symmetric |AES-wrap | |3-DES | > | |encryption of | | |(3-key-EDE, | > | |an end entity's| | |CBC Mode), | > | |private key | | |CAST-128, RC5| > | |where symmetric| | | | > | |key is | | | | > | |distributed | | | | > | |out-of-band | | | | > +------------+---------------+----------+-----------------+-------------+ > |PROT_ENC_ALG|asymmetric |D-H |ECDH, RSA | | > | |algorithm used | | | | > | |for encryption | | | | > | |of (symmetric | | | | > | |keys for | | | | > | |encryption of) | | | | > | |private keys | | | | > | |transported in | | | | > | |PKIMessages | | | | > +------------+---------------+----------+-----------------+-------------+ > |PROT_SYM_ALG|symmetric |AES-CBC | |3-DES | > | |encryption | | |(3-key-EDE, | > | |algorithm used | | |CBC Mode), | > | |for encryption | | |CAST-128, RC5| > | |of private key | | | | > | |bits (a key of | | | | > | |this type is | | | | > | |encrypted using| | | | > | |PROT_ENC_ALG) | | | | > +------------+---------------+----------+-----------------+-------------+ I really like this table. It's much clearer. > Currently we propose a mandatory algorithm use profile with 112bit strength. > As recommendations are going from RSA2048 to RSA3072 we discussed, if it is > better to make a profile mandatory offering 128 bit strength. > Currently we also mandate to use AES256 for key-wrap and encryption for > delivering centrally generated RSA2048 keys pairs. The encryption is stronger > than delivered key pair. Should we mandate AES128 only? Can you be more specific on which text says profiles have 112bits of strength and the KeyWrap+RSA guidance? Is the 112bits implicitly derived from using RSA-2048? AES128 + RSA2048 would be more consistent based on the principle of matching relative key strength. However, if prior specs said AES256+RSA2048, I think we should be careful about weaking the requirement regardless of consistency. > Currently HMAC and X9.9 are listed as OPTIONAL for MSG_MAC_ALG as they > were listed in RFC 4210 D.2. We propose to remove x9.9 and keep HMAC. > Regarding use of HMAC we would propose adding a Security Consideration as > follows. > > Symmetric key-based MAC algorithms as described in Section 6.2 MAY be > used as MSG_MAC_ALG. The implementor MUST choose a suitable PRF > and ensure that the key has sufficient entropy to match the overall security > level of the algorithm profile. These considerations are outside the scope > of the profile. I'm fine with keeping HMAC. I don't really know much about the user community of X9.9. It doesn't look like something we're recommend now. When you say remove it, do you mean SHOULD NOT/Deprecate column? We should also likely confirm that with the WG. > @Russ and Roman, what is your opinion? > > > > > ** Section 9. Can a reference be added for the theoretical weakness > > in PasswordBasedMac? > > We are not aware of any clear description of PasswordBasedMac weakness. > Therefor we propose the following change: > > Old > When using MAC-based message protection the use of PBMAC1 is > preferable to that of PasswordBasedMac: first, PBMAC1 is a well-known > scrutinized algorithm, which is not true for PasswordBasedMac and > second, there exists a theoretical weakness in PasswordBasedMac, > where the generated MAC key can be easily distinguished from a random > key. > > New > When using MAC-based message protection the use of PBMAC1 is preferable > to that of PasswordBasedMac. First, PBMAC1 is a well-known scrutinized > algorithm, which is not true for PasswordBasedMac. Second, the > PasswordBasedMac algorithm as specified in RFC 4211 section 4.4 is essentially > PBKDF1 (as defined in RFC 2898 section 5.1) with an HMAC step at the end. > Here we update to use the PBKDF2-HMAC construct defined as PBMAC1 in RFC > 8018. PBKDF2 is superior to PBKDF1 in an improved internal construct for > iterated hashing, and in removing PBKDF1's limitation of only being able to > derive keys up to the size of the underlying hash function. Additionally, PBKDF1 > is not recommended for new applications as stated in Section 5 of RFC 8018 > and no longer an approved algorithm by most standards bodies, and therefore > presents difficulties to implementors who are submitting their CMP > implementations for certification, hence moving to a PBKDF2-based > mechanism. This change is in alignment with RFC 9045 which updates RFC > 4211 to allow the use of PBMAC1 in CRMF. This is much clearer. Thanks. > > > > ** Section 9. Editorially, the first paragraph ("RFC 4210 Appendix > > D.2 ...) and the two paragraphs of "In Section 7 ..." and "To keep the > > list ...", seem to be saying the same thing. Recommend a merge. > > > > Okay, maybe we just remove the paragraph "To keep the list of algorithms" > > > ** Section 9. > > In such systems the weakened algorithms should > > be disabled from further use. > > > > Can this document make stronger recommendations about deprecating > > certain algorithms such as 3-DES SHA-1 with normative language rather > > than keeping it in the "other" category in the profiles? > > We updated Table 1 in Section 7.1 accordingly. Use of MD5, SHA-1, 3-DES, > CAST-128, and RC5 is deprecated. > Therefore we propose updating the section as follows. > > Old > It is recognized that there may be older CMP implementations in use > that conform to the algorithm use profile from Appendix D.2 of > RFC 4210 [RFC4210]. For example, the use of AES is now mandatory for > PROT_SYM_ALG but in RFC 4210 [RFC4210] 3-DES was mandatory. In most > cases the newer mandatory algorithms were listed as "other" > algorithms in RFC 4210 [RFC4210]. Therefore, it is expected that > many CMP systems may already support the recommended algorithms in > this specification. In such systems the weakened algorithms should > be disabled from further use. If critical systems cannot be > immediately updated to conform to the recommended algorithm use > profile, it is recommended a plan to migrate the infrastructure to > conforming profiles be adopted as soon as possible. > > New > It is recognized that there may be older CMP implementations in use > that conform to the algorithm use profile from Appendix D.2 of > RFC 4210 [RFC4210]. For example, the use of AES is now mandatory for > PROT_SYM_ALG but in RFC 4210 [RFC4210] 3-DES was mandatory. > Therefore, it is expected that > many CMP systems may already support the recommended algorithms in > this specification. In such systems the weakened algorithms should > be disabled from further use. If critical systems cannot be > immediately updated to conform to the recommended algorithm use > profile, it is recommended a plan to migrate the infrastructure to > conforming profiles be adopted as soon as possible. Thanks for the text. Regards, Roman > Hendrik
- [lamps] AD review of draft-ietf-lamps-cmp-algorit… Roman Danyliw
- Re: [lamps] AD review of draft-ietf-lamps-cmp-alg… Brockhaus, Hendrik
- Re: [lamps] AD review of draft-ietf-lamps-cmp-alg… Roman Danyliw
- Re: [lamps] AD review of draft-ietf-lamps-cmp-alg… Brockhaus, Hendrik
- Re: [lamps] AD review of draft-ietf-lamps-cmp-alg… Roman Danyliw
- Re: [lamps] AD review of draft-ietf-lamps-cmp-alg… Brockhaus, Hendrik
- Re: [lamps] AD review of draft-ietf-lamps-cmp-alg… Roman Danyliw
- Re: [lamps] AD review of draft-ietf-lamps-cmp-alg… Mike Ounsworth
- Re: [lamps] AD review of draft-ietf-lamps-cmp-alg… Brockhaus, Hendrik