Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Tue, May 11, 2021 at 4:16 PM Ben Schwartz wrote: > > > On Tue, May 11, 2021 at 4:13 PM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > ... > >> What is the difference between >> >> foo.example.com HTTPS 0 foo.example.net >> >> and >> >> foo.example.com HTTPS 1 foo.example.net >> >> (

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Tue, May 11, 2021 at 4:00 PM Ben Schwartz wrote: > > > On Tue, May 11, 2021 at 3:44 PM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > >> >> >> On Tue, May 11, 2021 at 2:49 PM Ben Schwartz wrote: >> >>> >>> >>> On Tue, May 11, 2021 at 2:31 PM Brian Dickson < >>> brian.peter.dick...@

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Tue, May 11, 2021 at 2:49 PM Ben Schwartz wrote: > > > On Tue, May 11, 2021 at 2:31 PM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > ... > >> Another way to put it is, the SvcParameters are actually bound to the >> TargetName, not the owner name of the HTTPS record, and the Web/CDN

Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance

Wes Hardaker wrote: > Vladimír Čunát writes: > > > I'd also expect something on limits accepted by secondaries.  And some > > details are probably up to further discussion (e.g. particular numbers > > and SERVFAIL), but I don't think such details would block adoption. > > That's certainly an inte

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Tue, May 11, 2021 at 11:12 AM Ben Schwartz wrote: > > > On Tue, May 11, 2021 at 10:32 AM Joe Abley wrote: > >> On 11 May 2021, at 12:32, Ben Schwartz wrote: >> >> > On Tue, May 11, 2021 at 9:20 AM Joe Abley wrote: >> >> On 11 May 2021, at 12:08, Ben Schwartz > 40google@dmarc.ietf.org> w

Re: [DNSOP] ZONEMD was Re: [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

While it is not written down that it is frozen you are required to give enough information to implement it with the expectation that it will be implemented by multiple vendors. Once implemented you then have to deal with backwards compatibility with existing implementations if changes are made

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Tue, May 11, 2021 at 10:32 AM Joe Abley wrote: > On 11 May 2021, at 12:32, Ben Schwartz wrote: > > > On Tue, May 11, 2021 at 9:20 AM Joe Abley wrote: > >> On 11 May 2021, at 12:08, Ben Schwartz 40google@dmarc.ietf.org> wrote: > >> .. > >>> * It saves at least 11 bytes of overhead per pa

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On 11 May 2021, at 12:32, Ben Schwartz wrote: > On Tue, May 11, 2021 at 9:20 AM Joe Abley wrote: >> On 11 May 2021, at 12:08, Ben Schwartz >> wrote: >> .. >>> * It saves at least 11 bytes of overhead per parameter by avoiding >>> repetition of >>> the name, type, class, TTL, and inter-pair

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Tue, May 11, 2021 at 9:41 AM Dick Franks wrote: > All, > > As part of a side discussion, I was admonished for my rather flippant > approach to a significant security issue and failure to explain > clearly how it manifests itself.. > > On Sun, 9 May 2021 at 13:01, Dick Franks wrote: > >8 > > >

[DNSOP] IPR Disclosure VeriSign, Inc.'s Statement about IPR related to draft-ietf-dnsop-qname-minimisation and RFC 7816

Dear Stéphane Bortzmeyer: An IPR disclosure that pertains to your RFC entitled "DNS Query Name Minimisation to Improve Privacy" (RFC7816) was submitted to the IETF Secretariat on 2021-05-07 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.iet

[DNSOP] IPR Disclosure VeriSign, Inc.'s Statement about IPR related to draft-ietf-dnsop-qname-minimisation and RFC 7816

Dear Stéphane Bortzmeyer: An IPR disclosure that pertains to your RFC entitled "DNS Query Name Minimisation to Improve Privacy" (RFC7816) was submitted to the IETF Secretariat on 2021-05-07 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.iet

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

All, As part of a side discussion, I was admonished for my rather flippant approach to a significant security issue and failure to explain clearly how it manifests itself.. On Sun, 9 May 2021 at 13:01, Dick Franks wrote: >8 > > Pre-processing of '\\,' into the RFC1035 standard '\,' is > superfic

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Tue, May 11, 2021 at 9:20 AM Joe Abley wrote: > Hi Ben, > > On 11 May 2021, at 12:08, Ben Schwartz > wrote: > .. > * It saves at least 11 bytes of overhead per parameter by avoiding > repetition of > the name, type, class, TTL, and inter-pair binding ID. > > > ... but it inflates response

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Hi Ben, Dne 11. 05. 21 v 18:08 Ben Schwartz napsal(a): On Tue, May 11, 2021 at 3:31 AM libor.peltan > wrote: If there really is a strong reason for putting multiple key-value records into one RData (instead of one RRSet), it should be described somewhe

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Hi Ben, On 11 May 2021, at 12:08, Ben Schwartz wrote: > OK, I've proposed text documenting the reasoning here: > https://github.com/MikeBishop/dns-alt-svc/pull/323/files > . I definitely appreciate the effort, since I think I agree th

Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance

Vladimír Čunát writes: Hi Vladimír, Thanks for the comments. > I'd also expect something on limits accepted by secondaries.  And some > details are probably up to further discussion (e.g. particular numbers > and SERVFAIL), but I don't think such details would block adoption. That's certainly

Re: [DNSOP] ZONEMD was Re: [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

> On May 10, 2021, at 5:44 PM, Mark Andrews wrote: > > >> On 11 May 2021, at 09:20, Paul Hoffman wrote: >> >> On May 10, 2021, at 4:14 PM, Mark Andrews wrote: >>> Actually, the process problem is that record format keeps changing AFTER >>> the code point has been assigned and the record fo

Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance

Olafur Gudmundsson writes: > I guess I support the document but would like it to say > “Please do not use NSEC3 but if you have to use NSEC3 use it use these > settings” Thanks Olafur. I think we originally had some text in there like that, but took it out. It looks like (currently) there may

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On 11. 05. 21 1:59, Brian Dickson wrote: IMNSHO, it'll be faster to discard any existing parsing code, and embrace this as the Zone File format (and wire format) going forward. I think that would imply burning the currently allocated RRtype code pair and requesting a new pair from IANA.  Not u

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Hi all, this is actually not the first time someone has come with this issue: https://mailarchive.ietf.org/arch/browse/dnsop/?gbt=1&index=WxZLxeJF3vSHiOG0jGm8kek5ajI If there really is a strong reason for putting multiple key-value records into one RData (instead of one RRSet), it should be d

Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance

I will contribute text, review, etc. It is suitable for adoption by DNSOP. Roy > On 10 May 2021, at 09:55, Benno Overeinder wrote: > > Hi all, > > As a follow-up to the presentation by Wes Hardaker at the IETF 110 DNSOP > meeting, we want to start a call for adoption of > draft-hardaker-dns

Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance

I support the document to become a working group document, and I am willing to review. Best regards, Matthijs On 10-05-2021 10:55, Benno Overeinder wrote: Hi all, As a follow-up to the presentation by Wes Hardaker at the IETF 110 DNSOP meeting, we want to start a call for adoption of draft