Re: [DNSOP] [Ext] Fwd: DNSSEC algorithm used on ietf.org

Petr Menšík <pemensik@redhat.com> Wed, 23 March 2022 17:04 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 DCC5D3A1924 for <dnsop@ietfa.amsl.com>; Wed, 23 Mar 2022 10:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0PZAZ4vXHKp for <dnsop@ietfa.amsl.com>; Wed, 23 Mar 2022 10:04:35 -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 EAE663A1930 for <dnsop@ietf.org>; Wed, 23 Mar 2022 10:04:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1648055069; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=53WXfr2gOqjm2/71eWJFURziHdruz2fGQdExbz47Ywg=; b=U0+A6sjprrIk7tD5mFYdTqfZSMwDx8fl5DXS93Ja0s3QZHy0S9bolIEyMqB7VsoKEdE/p6 HPTCD3qLtBj835Fhgi79vpLe7rK1Amt3TZ3oR0IsHQN9E2/ZPUoTlHU09I9Q+L+TVkhzC7 EtvAdJg5C14J6MWsJtaqrMEcxpDVEmg=
Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-15-dsaOzs2vO0OoF5BbO2PyYg-1; Wed, 23 Mar 2022 13:04:27 -0400
X-MC-Unique: dsaOzs2vO0OoF5BbO2PyYg-1
Received: by mail-wm1-f69.google.com with SMTP id l7-20020a05600c1d0700b0038c9c48f1e7so3067002wms.2 for <dnsop@ietf.org>; Wed, 23 Mar 2022 10:04:26 -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 :content-language:to:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=53WXfr2gOqjm2/71eWJFURziHdruz2fGQdExbz47Ywg=; b=ZllRY6HRR92kG7BVO2VOlPnGu4OtvwL6tVkj0A2qrS3HVJkikvIz7WXTfTgb9bUyO/ Y9EdGHHsaPHRDWe0HGkazWAyhsCn6vHHoGfbtxJmdf9dF8OH3BC9KZsqvUcHWwzA2Lpp dnYiEvXm0nGQkGZXLnbymQMl6zstJyTDqpG7xLASvBHf/WLX4DC6AYaCpD+SS/wLDfHL oMgh51QQRXbq1VydovdVpFs2o8+tahEoaNS1KmnrPf5bsd+zbnzIwpxTyj/2AGQBy/G8 rhdkqPe+nBzO9rzZt3zMRIlIDd3TvmfRNo3bi6aXIRqhXm4cxev6+cJPC9vqL14F0pwr h9NA==
X-Gm-Message-State: AOAM5330VJc7onmoVk2N1w8EkgYSqBvJ9+JFU4zev0E8ej/GB1NblKAx t+l9vA1UGsRR8YlSo3B8/vlpuSy9i0gvGdYF199ipngByD4II67msnwfyB9bZw1cDYiOKEBZCKY Z1IapzLZTOYoSKtbFvsIbLn85fgCELGHtnnv/rBWlHpn235htPOrVc3VMCA==
X-Received: by 2002:a5d:5889:0:b0:204:1ccf:a04 with SMTP id n9-20020a5d5889000000b002041ccf0a04mr755034wrf.197.1648055065752; Wed, 23 Mar 2022 10:04:25 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJywLmIzBnwNVpNyt1dyXon74pbExJn7hhvD6faIMj+0U9Xftm4mHe2gGKEkaaXeLHKvp1948Q==
X-Received: by 2002:a5d:5889:0:b0:204:1ccf:a04 with SMTP id n9-20020a5d5889000000b002041ccf0a04mr754998wrf.197.1648055065362; Wed, 23 Mar 2022 10:04:25 -0700 (PDT)
Received: from [10.43.2.33] (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id a11-20020a5d456b000000b0020406ce0e06sm317837wrc.94.2022.03.23.10.04.24 for <dnsop@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Mar 2022 10:04:25 -0700 (PDT)
Message-ID: <c1c4f10f-0b9e-b390-904b-5b5643d5a650@redhat.com>
Date: Wed, 23 Mar 2022 18:04:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
To: dnsop@ietf.org
References: <d383a88c-46cc-8252-3670-b30f68acdf44@redhat.com> <f45a40c7-f265-8e39-963b-2f6434afa18c@redhat.com> <40D559B1-174A-44AE-BAE0-6A0F41D6BFD9@icann.org>
From: Petr Menšík <pemensik@redhat.com>
Organization: Red Hat
In-Reply-To: <40D559B1-174A-44AE-BAE0-6A0F41D6BFD9@icann.org>
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-Language: en-US
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1oZBR_o_uNO3A_D5q0jGk068Lr8>
Subject: Re: [DNSOP] [Ext] Fwd: DNSSEC algorithm used on ietf.org
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 23 Mar 2022 17:04:46 -0000

On 3/23/22 15:56, Paul Hoffman wrote:
> On Mar 23, 2022, at 7:30 AM, Petr Menšík <pemensik@redhat.com> wrote:
>> Is this workgroup more appropriate to drive possible change? Has it any means to modify ietf.org infrastructure?
> No and no.
>
> Having said that, please see below for commentary on your reasoning.
>
>> -------- Forwarded Message --------
>> Subject:	DNSSEC algorithm used on ietf.org
>> Date:	Wed, 23 Mar 2022 12:28:39 +0100
>> From:	Petr Menšík <pemensik@redhat.com>
>> Organization:	Red Hat
>> To:	tools-discuss@ietf.org
>>
>>
>> Hello,
>>
>> I work in Red Hat on DNS related products. We were analysing impact on
>> disabling algorithm RSASHA1.
> The impact is clear: you will cause many validly-signed zones to be considered unsigned.
I am aware this would be the result. It were done in very similar manner
with RSAMD5. It is questionable anyway how secure it is, when its
operator does not follow up-to-date recommendation.
>
>> It is in a strange sitation, because IETF
>> itself deprecated this algorithm [1],
> Where in RFC 8624 do you believe it says that RSASHA1 is deprecated? Searching for "depreca" in the document finds it used for other algorithms, but not RSASHA1.
>
> Further, the chart clearly shows it is not deprecated:
>    +--------+--------------------+-----------------+-------------------+
>    | Number | Mnemonics          | DNSSEC Signing  | DNSSEC Validation |
>    +--------+--------------------+-----------------+-------------------+
> . . .
>    | 5      | RSASHA1            | NOT RECOMMENDED | MUST              |
>
> That is, "MUST" validate is clearly not deprecated.
>
> --Paul Hoffman

We are preparing RHEL 9 and we still have SHA-1 for DNS(SEC) as
exception. But we think it would happen when it would be under support.
Thank you for exact reference, it may be used in our internal discussion.

While it might not be required yet, it should be ready when that
happens. Is there expected timeline for that yet? Any required changes,
which may change validation to SHOULD or MAY? Is it just about DNSSEC
algorithms used on top level domains? Server configuration already makes
it possible to disable any algorithm, including RSASHA1. It must
implement it and it would. Question here is only whether it would be
disabled in default configuration or not.

We are not considering disabling its support at build time, it would be
always possible to enable later.

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB