[DNSOP] Last Call: (Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC) to Informational RFC
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2022-10-19. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC). This document obsoletes RFC 5933 and updates RFC 8624. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-dnssec-bcp-04.txt
On Oct 5, 2022, at 11:36 AM, Peter Thomassen wrote:
>
> On 10/5/22 20:25, Paul Hoffman wrote:
>>> On 10/5/22 19:56, Paul Hoffman wrote:
I propose to replace that paragraph with:
What we today call "DNSSEC" is the DNSSEC specification defined in
{{RFC4033}}, {{RFC4034}}, and {{RFC4035}}.
However, earlier incarnations of DNSSEC were thinly deployed and
significantly less
visible than the current DNSSEC specification.
>>>
>>> I think that's much better, but it remains vague in that it leaves open
>>> what those other versions were.
>>>
>>> I know there are some RFCs that defined KEY records etc. Is that's what's
>>> meant? Perhaps we should add something like:
For the historic record of these, see RFC 2535 and related documents.
>>>
>>> (Or whatever is the appropriate set of documents.)
>> Given that we don't have clear version numbers, I would kinda prefer not to
>> do that. Does RFC 2535 represent a clear description of an earlier
>> incarnation/version of DNSSEC? It doesn't feel that way to me.
> I wasn't around at that time, so I don't know. Based on the fact that the
> current incarnation was dubbed version 3, I assumed that other revisions can
> be pointed to more or less precisely. Apologies if I misunderstood.
>
> My point is precisely that if we can't pinpoint what we mean by "earlier
> incarnations", the text shouldn't sound like they were stable versions that
> were merely thinly deployed.
I fully agree that they shouldn't sound like stable versions, thus my use of
the vague word "incarnations". I'm happy to use a different word that is even
less version-like.
> So, my suggestion would be that if we know what those incarnations are, let's
> add references so people can dig further if they are interested. If we can't
> point to a specification and/or don't know what those incarnations are, I
> think it would be better to say they "... were not fully specified and saw
> only little deployment" or not talk about them at all.
I think we have to talk about them a bit so that the reader doesn't ask the
question "how come there are DNSSEC RFCs that vastly pre-date 4033?".
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-dnssec-bcp-04.txt
On 10/5/22 20:25, Paul Hoffman wrote:
On 10/5/22 19:56, Paul Hoffman wrote:
I propose to replace that paragraph with:
What we today call "DNSSEC" is the DNSSEC specification defined in {{RFC4033}},
{{RFC4034}}, and {{RFC4035}}.
However, earlier incarnations of DNSSEC were thinly deployed and significantly
less
visible than the current DNSSEC specification.
I think that's much better, but it remains vague in that it leaves open what
those other versions were.
I know there are some RFCs that defined KEY records etc. Is that's what's
meant? Perhaps we should add something like:
For the historic record of these, see RFC 2535 and related documents.
(Or whatever is the appropriate set of documents.)
Given that we don't have clear version numbers, I would kinda prefer not to do
that. Does RFC 2535 represent a clear description of an earlier
incarnation/version of DNSSEC? It doesn't feel that way to me.
I wasn't around at that time, so I don't know. Based on the fact that the
current incarnation was dubbed version 3, I assumed that other revisions can be
pointed to more or less precisely. Apologies if I misunderstood.
My point is precisely that if we can't pinpoint what we mean by "earlier
incarnations", the text shouldn't sound like they were stable versions that were
merely thinly deployed.
So, my suggestion would be that if we know what those incarnations are, let's add
references so people can dig further if they are interested. If we can't point to a
specification and/or don't know what those incarnations are, I think it would be better
to say they "... were not fully specified and saw only little deployment" or
not talk about them at all.
Best,
Peter
--
https://desec.io/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-dnssec-bcp-04.txt
> On Oct 5, 2022, at 11:00 AM, Peter Thomassen wrote:
>
> Hi,
>
> On 10/5/22 19:56, Paul Hoffman wrote:
>> I propose to replace that paragraph with:
>> What we today call "DNSSEC" is the DNSSEC specification defined in
>> {{RFC4033}}, {{RFC4034}}, and {{RFC4035}}.
>> However, earlier incarnations of DNSSEC were thinly deployed and
>> significantly less
>> visible than the current DNSSEC specification.
>
> I think that's much better, but it remains vague in that it leaves open what
> those other versions were.
>
> I know there are some RFCs that defined KEY records etc. Is that's what's
> meant? Perhaps we should add something like:
>> For the historic record of these, see RFC 2535 and related documents.
>
> (Or whatever is the appropriate set of documents.)
Given that we don't have clear version numbers, I would kinda prefer not to do
that. Does RFC 2535 represent a clear description of an earlier
incarnation/version of DNSSEC? It doesn't feel that way to me.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-dnssec-bcp-04.txt
What we today call "DNSSEC" is the DNSSEC specification defined in {{RFC4033}},
{{RFC4034}}, and {{RFC4035}}.
However, earlier incarnations of DNSSEC were thinly deployed and significantly
less
visible than the current DNSSEC specification.
Works for me.
regards
John
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-dnssec-bcp-04.txt
Hi,
On 10/5/22 19:56, Paul Hoffman wrote:
I propose to replace that paragraph with:
What we today call "DNSSEC" is the DNSSEC specification defined in {{RFC4033}},
{{RFC4034}}, and {{RFC4035}}.
However, earlier incarnations of DNSSEC were thinly deployed and significantly
less
visible than the current DNSSEC specification.
I think that's much better, but it remains vague in that it leaves open what
those other versions were.
I know there are some RFCs that defined KEY records etc. Is that's what's
meant? Perhaps we should add something like:
For the historic record of these, see RFC 2535 and related documents.
(Or whatever is the appropriate set of documents.)
Best,
Peter
--
https://desec.io/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-dnssec-bcp-04.txt
On Oct 5, 2022, at 10:44 AM, John Dickinson wrote:
>
> "What we today call "DNSSEC" is formally version 3 of the DNSSEC
> specification."
>
> The only version number I know of in DNSSEC is the Protocol Field in a DNSKEY
> RR. However this doesn't really version the whole of DNSSEC.
>
> So I think that either that sentence in the draft should be expanded to cover
> what the previous 2 versions were or be removed altogether.
Thanks John, this is a very good point. At a minimum, the version number 3 is
not defined anywhere in RFC 4033/4034/4035, so I should drop the word
"formally". Given that, the rest of that paragraph is kinda wonky too.
However, earlier versions of DNSSEC were thinly deployed and significantly less
visible than the current DNSSEC specification. Throughout this document,
"DNSSEC"
means version 3 of the protocol initially defined in {{RFC4033}}, {{RFC4034}},
and {{RFC4035}}.
I propose to replace that paragraph with:
What we today call "DNSSEC" is the DNSSEC specification defined in {{RFC4033}},
{{RFC4034}}, and {{RFC4035}}.
However, earlier incarnations of DNSSEC were thinly deployed and significantly
less
visible than the current DNSSEC specification.
Does that work with folks here?
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bcp-04.txt
On 05/10/2022 15:52, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : DNS Security Extensions (DNSSEC) Author : Paul Hoffman Filename: draft-ietf-dnsop-dnssec-bcp-04.txt Pages : 11 Date: 2022-10-05 Abstract: This document describes the DNS security extensions (commonly called "DNSSEC") that are specified RFCs 4033, 4034, 4035, and a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. Another purpose is to move DNSSEC to Best Current Practice status. This document is currently maintained at https://github.com/paulehoffman/draft-hoffman-dnssec. Issues and pull requests are welcomed. This is not a major issue but I have always wondered what the version number refers to in Section 2: "What we today call "DNSSEC" is formally version 3 of the DNSSEC specification." The only version number I know of in DNSSEC is the Protocol Field in a DNSKEY RR. However this doesn't really version the whole of DNSSEC. So I think that either that sentence in the draft should be expanded to cover what the previous 2 versions were or be removed altogether. regards John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bcp-04.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : DNS Security Extensions (DNSSEC) Author : Paul Hoffman Filename: draft-ietf-dnsop-dnssec-bcp-04.txt Pages : 11 Date: 2022-10-05 Abstract: This document describes the DNS security extensions (commonly called "DNSSEC") that are specified RFCs 4033, 4034, 4035, and a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. Another purpose is to move DNSSEC to Best Current Practice status. This document is currently maintained at https://github.com/paulehoffman/draft-hoffman-dnssec. Issues and pull requests are welcomed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bcp/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-bcp-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-bcp-04 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
