Re: [DNSOP] FIPS 140-3 mode on RHEL 9 and RSA validation of <2048 keys

Petr Menšík <pemensik@redhat.com> Tue, 17 May 2022 18:51 UTC

Return-Path: <pemensik@redhat.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AF9C15E41C for <dnsop@ietfa.amsl.com>; Tue, 17 May 2022 11:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.117
X-Spam-Level:
X-Spam-Status: No, score=-3.117 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIMWL_WL_HIGH=-0.575, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.857, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuMj9sjJqWgH for <dnsop@ietfa.amsl.com>; Tue, 17 May 2022 11:51:10 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 EF20BC159A3D for <dnsop@ietf.org>; Tue, 17 May 2022 11:51:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1652813468; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yGbusVBFKtnQXy86Cp0/1/t3adUsRRO7rXcx36WnSgk=; b=jEHVOSWppmkA2FhuXVPRS++rhyl0Rp0JsXS03+xsmnw0VqKZ3S6rKEOc3Ix83x7KLTme9l YSbF79tITFCUvEG9yY/M6VsoOjjQgU0Lssfspvz+SXNTR1gc4ME8MBi1wnwf8v/BPOqKAJ qf0jCb6wXl/uq40AOGzNYRQAuVE5JTg=
Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-483-wUbOTRr1Me699hcDdO4nPQ-1; Tue, 17 May 2022 14:51:06 -0400
X-MC-Unique: wUbOTRr1Me699hcDdO4nPQ-1
Received: by mail-ed1-f70.google.com with SMTP id bc17-20020a056402205100b0042aa0e072d3so9355edb.17 for <dnsop@ietf.org>; Tue, 17 May 2022 11:51:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:from:to:references:in-reply-to; bh=yGbusVBFKtnQXy86Cp0/1/t3adUsRRO7rXcx36WnSgk=; b=P186IBY0axeE6Aah0dZUC7bAXCjkzylGCHN5d1hHet3mNvwjYjmRH1uEg7z7GLQPR3 7gk+gtkMIPWmv07Lq/gZr2+iyyWUflr5YHAAdCDBx1CtEpFw8jUZc45r0UQJitvwnv6h a0G4K5xWbQISpJOpKiPBX8ANQdCt3D1XuqfD8v+6V953FW2Pzld+mpln99jjb0d3c6t0 WoTV4efZFBJY6eVMyImoIYwp3WRAMkVKlIkJfrNwBpr8NRYb+Kcfzuf87f9PH6Y7naVJ SdZMz8sajO1QKh9OhhMPHZZN5KcQv3HE5SH8rewoaCRm9agQhX8LnuvKSshEiZcOCD+e q6JA==
X-Gm-Message-State: AOAM530/LOlnkRwAn3mm2I0W9yO6Bq0cf+uMJfm9aLrhdWXkvP++ASyJ IFWM3+HYajtxoLI+g6SD/2xtJ2+QvO0o7yzm/GX8wA4DfnQtRrztYQfKbiW+4GzvdzAl1yqPcg/ vs8W2ievOXa53v+g7tiCqJn9t8F4HtJp8PMA7iVz55sdHh4bREF9NatYB1A==
X-Received: by 2002:a05:6402:190a:b0:427:efb7:bd81 with SMTP id e10-20020a056402190a00b00427efb7bd81mr20888149edz.63.1652813465522; Tue, 17 May 2022 11:51:05 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJzibd6NIbBWci8jdo6r/Wr0VJpjIsu6X9AwFOKKs0BpTcR6N+vMM8PvJdKtJp2CR/nuHxVeGw==
X-Received: by 2002:a05:6402:190a:b0:427:efb7:bd81 with SMTP id e10-20020a056402190a00b00427efb7bd81mr20888128edz.63.1652813465167; Tue, 17 May 2022 11:51:05 -0700 (PDT)
Received: from [192.168.88.133] ([46.149.126.14]) by smtp.gmail.com with ESMTPSA id p25-20020aa7c4d9000000b004278942f86asm39465edr.7.2022.05.17.11.51.04 for <dnsop@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 May 2022 11:51:04 -0700 (PDT)
Message-ID: <9f866bd7-430a-4e0e-cb2f-8f9c0dd54a71@redhat.com>
Date: Tue, 17 May 2022 20:51:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0
From: =?UTF-8?B?UGV0ciBNZW7FocOtaw==?= <pemensik@redhat.com>
To: dnsop@ietf.org
References: <356059e5-e973-3d6c-569c-9ff9d9fe16e6@redhat.com> <87v8uxh45n.fsf@miraculix.mork.no> <1b18282e-b1d6-797f-644f-e0b6c59a0b03@redhat.com>
In-Reply-To: <1b18282e-b1d6-797f-644f-e0b6c59a0b03@redhat.com>
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=pemensik@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: multipart/alternative; boundary="------------b8X06c4yzVNEa28QTTNS1jvC"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pz8lJfTgt3P_FinWBKfAYB0XGXs>
Subject: Re: [DNSOP] FIPS 140-3 mode on RHEL 9 and RSA validation of <2048 keys
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 May 2022 18:51:14 -0000

I am sorry it took so long.

Our intention is to get rid of RSA < 2048b, because they are considered 
too weak, 829 bits key was factorized in 2020 [1]. However the FIPS team 
is aware it is technically permissible to do just verification with 
smaller key size and is evaluating the impact. The FIPS team also thinks 
adoption of strong enough algorithms in DNSSEC is very slow. Web PKI has 
moved to 2048b keys in 2013 [2].


The legacy use in FIPS mode is not very well defined. The FIPS team 
thinks legacy use should cover only signatures made when those keys were 
considered secure, which would be application-specific and which might 
not solve the DNSSEC problem as it is using smaller keys deliberately 
because of technical limitations with larger keys. Not fresh signatures 
with a short expiration period and refreshed periodically.


Also, NIST SP 800-131Ar2 document [3] mentions legacy use of any key 
equal or above 1024 bits. But FIPS 140-3 Implementation Guidelines [4] 
mention explicitly only keys exactly 1024 bits, otherwise only allowed 
keys are those permitted to be generated. That would be >=2048 bits, 
that is clear enough.

Fortunately NIST labs gave as a green flag and agreed legacy use is okay 
also for higher sizes. It seems it would break on few shorter keys, but 
most of domains still can be validated. I would try modification of 
shipped validators to pass on shorter key.

Overall there is no sensation or critical breakage which I expected for 
some time. I am sorry for a disturbance caused. Only minor issues will 
arise. Thank you for your attention and I hope I haven't caused any harm.

Best Regards, Petr Menšík



 1.

    https://en.wikipedia.org/wiki/RSA_numbers#RSA-250

 2.

    https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf
    <https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf>

 3.

    https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.3.pdf
    <https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.3.pdf>

 4.

    https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf
    <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf>


On 27. 04. 22 14:16, Petr Menšík wrote:
> Thank you for those references, they are very useful.
>
> I need to discuss our stance internally first. I think we should have a
> better response prepared.
>
> It may take a few days to formulate and explain our direction.
>
> Thanks,
> Petr
>
> On 4/25/22 12:02, Bjørn Mork wrote:
>> Petr Menšík<pemensik@redhat.com>  writes:
>>
>>> Our crypto team is
>>> responsible for preparing RHEL 9 for FIPS 140-3 certification. They said
>>> there is legal obligation to stop using all RSA signatures with keys
>>> shorter than 2048 bits.
>> Either they're wrong or you're misquoting them by merging "signing" and
>> "verifying" into the confusing and misleading term "using".  FIPS 140-3
>> is a bit more specific than that, fortunately.
>>
>> See table 2 in
>> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf
>> which shows the status of RSA keys with 1024 ≤ len(n) < 2048 for Digital
>> Signature Verification as "Legacy use".
>>
>> The text following that table provides more detail:
>>
>>    Key lengths providing less than 112 bits of security that were
>>    previously specified in FIPS 186 are allowed for legacy use when
>>    verifying digital signatures.
>>
>> and
>>
>>    RSA: See FIPS 186-239 and FIPS 186-4,40 which include modulus lengths
>>    of 1024, 1280, 1536 and 1792 bits, may continue to be used for
>>    signature verification but not signature generation
>>
>>
>> Bjørn
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop