Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Wed, Jan 6, 2021 at 2:15 PM Paul Wouters wrote: > On Jan 6, 2021, at 17:01, Eric Rescorla wrote: > > > > > > This is not strictly correct: TLS allows both the client and the server > to advertise their supported signature algorithms, which can be used by the > peer to guide certificate select

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Jan 6, 2021, at 17:01, Eric Rescorla wrote: > > > This is not strictly correct: TLS allows both the client and the server to > advertise their supported signature algorithms, which can be used by the peer > to guide certificate selection. How common is it for TLS servers to have multiple s

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Jan 6, 2021, at 16:30, Paul Hoffman wrote: > > On Jan 6, 2021, at 1:19 PM, Paul Wouters wrote: >> Remember also that TLS ciphers are negotiated. > > A better analogy might be "although TLS key exchange and encryption ciphers > are negotiated, the signing algorithm on the server's certifica

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Jan 6, 2021, at 2:00 PM, Eric Rescorla wrote: > This is not strictly correct: TLS allows both the client and the server to > advertise their supported signature algorithms, which can be used by the peer > to guide certificate selection. Fair point. However, if the TLS client says "I support

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Wed, Jan 6, 2021 at 1:30 PM Paul Hoffman wrote: > On Jan 6, 2021, at 1:19 PM, Paul Wouters wrote: > > Remember also that TLS ciphers are negotiated. > > A better analogy might be "although TLS key exchange and encryption > ciphers are negotiated, the signing algorithm on the server's certific

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Jan 6, 2021, at 1:19 PM, Paul Wouters wrote: > Remember also that TLS ciphers are negotiated. A better analogy might be "although TLS key exchange and encryption ciphers are negotiated, the signing algorithm on the server's certificate is not negotiated". DNSSEC signing is much more akin to

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Wed, 6 Jan 2021, Ben Schwartz wrote: Also, you would end up building a list of algorithms from worst to best. This is not always obvious. Sure, the SHA1 vs SHA2 is obvious. Would you prefer a NIST ECC curve over a GOST ECC curve or not? TLS implementations always have a pre

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

> On 6 Jan 2021, at 20:48, Ben Schwartz > wrote: > >> > Telling validators to "insist" that all signatures are valid would resolve >> > this dilemma. Zone owners could add algorithms without weakening anything. >> >> How do you deploy a new signing algorithm alongside an established one >>

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On 6 Jan 2021, at 15:48, Ben Schwartz wrote: > On Wed, Jan 6, 2021 at 3:37 PM Joe Abley > wrote: > On Jan 6, 2021, at 14:45, Ben Schwartz > wrote: > > > That model works well when (a) all validators implement an algorithm you > >

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Jan 6, 2021, at 14:45, Ben Schwartz wrote: > That model works well when (a) all validators implement an algorithm you like > OR (b) you view each algorithm as either "definitely strong" or "worthless" > (no middle ground). We are in scenario (b). When you sign a zone you choose one or mo

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Wed, Jan 6, 2021 at 9:57 AM Paul Wouters wrote: > On Tue, 5 Jan 2021, Ben Schwartz wrote: > > > One thing I found surprising here is that RFC 6840 Section 5.11 says > >Validators > >SHOULD accept any single valid path. They SHOULD NOT insist that all > >algorithms signaled in the

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Tue, 5 Jan 2021, Ben Schwartz wrote: One thing I found surprising here is that RFC 6840 Section 5.11 says    Validators    SHOULD accept any single valid path.  They SHOULD NOT insist that all    algorithms signaled in the DS RRset work, and they MUST NOT insist    that all algorithms signale

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

> 6 янв. 2021 г., в 06:45, Ben Schwartz написал(а): > > One thing I found surprising here is that RFC 6840 Section 5.11 says > >Validators >SHOULD accept any single valid path. They SHOULD NOT insist that all >algorithms signaled in the DS RRset work, and they MUST NOT insist >

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

> 4 янв. 2021 г., в 19:20, Stephen Farrell > написал(а): > > > Hiya, > > On 04/01/2021 16:05, Paul Wouters wrote: >> While asking is fair, you would also have to define what you >> do based on the outcome of that ask. You left that out, > > I don't think I did omit that. My stated reason to

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Jan 4, 2021, at 8:33 AM, Jim Reid wrote: > > > >> On 4 Jan 2021, at 16:18, Paul Wouters wrote: >> >> You want to see a Status column at the IANA registry for marking >> something "NOT RECOMMENDED" / "DEPRECATED" etc ? > > Yes! If the WG adopts the draft, it sounds like the WG might want

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

> On 4 Jan 2021, at 16:18, Paul Wouters wrote: > > You want to see a Status column at the IANA registry for marking > something "NOT RECOMMENDED" / "DEPRECATED" etc ? Yes! ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

Hiya, On 04/01/2021 16:05, Paul Wouters wrote: While asking is fair, you would also have to define what you do based on the outcome of that ask. You left that out, I don't think I did omit that. My stated reason to ask was to help me figure out what I think about the draft named in the subje

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Mon, 4 Jan 2021, Jim Reid wrote: Maybe there needs to be another I-D to document the process for adding and deprecating DNSSEC type codes? You mean something in addition to RFC 8624 ? You want to see a Status column at the IANA registry for marking something "NOT RECOMMENDED" / "DEPRECATE

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Mon, 4 Jan 2021, Stephen Farrell wrote: WRT GOST, we're not really talking about an algorithm but rather a national crypto standards scheme that selects sets of algorithms. For such things, whether from Russia or the US or anywhere, I think it's quite fair to ask "how has version N dep

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

> On 4 Jan 2021, at 15:27, Stephen Farrell wrote: > > On 04/01/2021 14:23, Paul Wouters wrote: >> On Mon, 4 Jan 2021, Stephen Farrell wrote: >>> WRT GOST, we're not really talking about an algorithm but >>> rather a national crypto standards scheme that selects sets >>> of algorithms. For such

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Mon, Jan 04, 2021 at 04:21:10AM -0800, Eric Rescorla wrote: > On Mon, Jan 4, 2021 at 3:31 AM Vittorio Bertola 40open-xchange@dmarc.ietf.org> wrote: > > ... > > This seems to conflate standardization with code point assignment. > Standards are recommendations and our recommendation is that

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

Hiya, On 04/01/2021 14:23, Paul Wouters wrote: On Mon, 4 Jan 2021, Stephen Farrell wrote: WRT GOST, we're not really talking about an algorithm but rather a national crypto standards scheme that selects sets of algorithms. For such things, whether from Russia or the US or anywhere, I think it

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Mon, 4 Jan 2021, Stephen Farrell wrote: WRT GOST, we're not really talking about an algorithm but rather a national crypto standards scheme that selects sets of algorithms. For such things, whether from Russia or the US or anywhere, I think it's quite fair to ask "how has version N deployment

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

Hiya, On 04/01/2021 11:31, Vittorio Bertola wrote: We could ask the proponents of new algorithms for information on current or expected usage. WRT GOST, we're not really talking about an algorithm but rather a national crypto standards scheme that selects sets of algorithms. For such things,

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Mon, Jan 4, 2021 at 3:31 AM Vittorio Bertola wrote: > > > > Il 01/01/2021 19:42 Stephen Farrell ha > scritto: > > > > > > Hiya, > > > > On 01/01/2021 17:58, Paul Hoffman wrote: > > > The WG has already adopted the revised GOST document as a WG item; > > > what you are proposing (if the curren

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

> Il 01/01/2021 19:42 Stephen Farrell ha scritto: > > > Hiya, > > On 01/01/2021 17:58, Paul Hoffman wrote: > > The WG has already adopted the revised GOST document as a WG item; > > what you are proposing (if the current use is negligible) would be in > > the opposite direction. > I wasn't

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

Hiya, On 01/01/2021 17:58, Paul Hoffman wrote: The WG has already adopted the revised GOST document as a WG item; what you are proposing (if the current use is negligible) would be in the opposite direction. I wasn't "proposing" that, just posing it as a possible option that might or might not

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Jan 1, 2021, at 8:53 AM, Stephen Farrell wrote: > > I note that you didn't answer my question about actual use > of gost and guess that's because you don't have that data > to hand. I'm still interested in that if someone has info > because grounding this in reality seems likely better. Corre

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

Hiya, I note that you didn't answer my question about actual use of gost and guess that's because you don't have that data to hand. I'm still interested in that if someone has info because grounding this in reality seems likely better. On 01/01/2021 16:38, Paul Hoffman wrote: The status quo (s

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Dec 31, 2020, at 2:09 PM, Stephen Farrell wrote: > > > Hiya, > > On 31/12/2020 21:48, Eric Rescorla wrote: >> 1. Don't allocate a code point at all >> 2. Allocate the code point but in some manner that makes clear >>we don't endorse it (effectively what TLS does for algorithms >>like

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

Hiya, On 31/12/2020 21:48, Eric Rescorla wrote: 1. Don't allocate a code point at all 2. Allocate the code point but in some manner that makes clear we don't endorse it (effectively what TLS does for algorithms like this) 3. Allocate the code point without comment FWIW, I kind of agre

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Wed, Dec 30, 2020 at 7:23 PM Paul Wouters wrote: > On Dec 30, 2020, at 22:11, Daniel Migault wrote: > > > >  > > > > If I understand clearly the comment, it seems to say that TLS ( for > example ) is using RFC Required and that DNSSEC should do the same. Quickly > going through RFC 8447, I

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Wed, Dec 30, 2020 at 10:22 PM Paul Wouters wrote: > On Dec 30, 2020, at 22:11, Daniel Migault wrote: > > > >  > > > > If I understand clearly the comment, it seems to say that TLS ( for > example ) is using RFC Required and that DNSSEC should do the same. Quickly > going through RFC 8447, I

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Dec 30, 2020, at 22:11, Daniel Migault wrote: > >  > > If I understand clearly the comment, it seems to say that TLS ( for example ) > is using RFC Required and that DNSSEC should do the same. Quickly going > through RFC 8447, I cannot find "RFC Required", so I am wondering if you have >

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

Hi Tim, Just to answer the question and maybe clarify my opinion. I also considered that we might need some experimental RFCs, but came to the conclusion that it was not necessary. The experimentation seems quite straight forward. On the other hand, I see two issues with allocating code points wit

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

Hi, Thanks for your questions, please see inline some clarifications. Yours, Daniel On Fri, Dec 25, 2020 at 3:27 PM Paul Hoffman wrote: > On Dec 24, 2020, at 10:28 AM, Daniel Migault wrote: > > > > Hi, > > > > As the DNS is a global shared resource and its reliability is based on > **all** pi

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Dec 27, 2020, at 10:40 AM, Tim Wicinski wrote: > > (Speaking without my chairs hat here) > > How about instead of loosening the requirement, we take the top 64 values, > allocate them as either Experimental or FCFS, and it is explicitly noted NOT > REQUIRED (or NO ONE WILL IMPLEMENT THESE F

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

Hi, > > How about instead of loosening the requirement, we take the top 64 values, > > allocate them as > > either Experimental or FCFS, and it is explicitly noted NOT REQUIRED (or NO > > ONE WILL IMPLEMENT > > THESE FOR YOU). > > > > That would leave the registry with the strict requirements an

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Sun, 27 Dec 2020, Tim Wicinski wrote: How about instead of loosening the requirement, we take the top 64 values, allocate them as either Experimental or FCFS, and it is explicitly noted NOT REQUIRED (or NO ONE WILL IMPLEMENT THESE FOR YOU). That would leave the registry with the strict req

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

(Speaking without my chairs hat here) How about instead of loosening the requirement, we take the top 64 values, allocate them as either Experimental or FCFS, and it is explicitly noted NOT REQUIRED (or NO ONE WILL IMPLEMENT THESE FOR YOU). That would leave the registry with the strict requiremen

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

> On Dec 25, 2020, at 3:27 PM, Paul Hoffman wrote: > > On Dec 24, 2020, at 10:28 AM, Daniel Migault > wrote: >> >> Hi, >> >> As the DNS is a global shared resource and its reliability is based on >> **all** pieces of software adhering a common standard, I am inc

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Dec 24, 2020, at 10:28 AM, Daniel Migault wrote: > > Hi, > > As the DNS is a global shared resource and its reliability is based on > **all** pieces of software adhering a common standard, I am inclined to > believe that new cryptographic algorithms introduced with anything less > restric

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Thu, Dec 24, 2020 at 01:28:59PM -0500, Daniel Migault wrote: > Hi, > > As the DNS is a global shared resource and its reliability is based on > **all** pieces of software adhering a common standard, I am inclined to > believe that new cryptographic algorithms introduced with anything less > res

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

Hi, As the DNS is a global shared resource and its reliability is based on **all** pieces of software adhering a common standard, I am inclined to believe that new cryptographic algorithms introduced with anything less restrictive than "IETF Review" - such as "Specification Required" and "RFC Requ

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Dec 11, 2020, at 8:26 AM, Tim Wicinski wrote: > > > > This draft was present at IETF108 and IETF109. There was interest in adopting > this, but I do recall that implementors had some concerns about this. > However, there was enough interest in starting an adoption > call on this. > > >