Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

In article you write: >Yep, I suspect some of the bigger TLDs probably couldn't opt in to this >draft simply because they're full of, um, "history". Until that history >is cleaned, they probably couldn't deploy it. It's not just history. All of the nominet TLDs and many Verisign TLDs have

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

Hi Mark, On 30 Apr 2020, at 19:52, Mark Andrews wrote: > On 1 May 2020, at 08:39, Wes Hardaker wrote: > >> Yep, I suspect some of the bigger TLDs probably couldn't opt in to this >> draft simply because they're full of, um, "history". Until that history >> is cleaned, they probably couldn't

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

> On 1 May 2020, at 08:39, Wes Hardaker wrote: > > Joe Abley writes: > >> Well, for example there are some 28,000 examples of orphan glue in the >> ORG zone. > > Yep, I suspect some of the bigger TLDs probably couldn't opt in to this > draft simply because they're full of, um, "history".

Re: [DNSOP] I-D Action: draft-pwouters-powerbind-04.txt

internet-dra...@ietf.org writes: > 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. Per discussion in the adoption thread, this primarily updates sections 1 and 3 with a stronger

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

Joe Abley writes: > Well, for example there are some 28,000 examples of orphan glue in the > ORG zone. Yep, I suspect some of the bigger TLDs probably couldn't opt in to this draft simply because they're full of, um, "history". Until that history is cleaned, they probably couldn't deploy it.

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

Hi Wes. On 30 Apr 2020, at 17:41, Wes Hardaker wrote: > I've just pushed the -04 version of the draft that has a fairly major > overhaul of the problem statement. I'd appreciate if it helps clarify > the technical reasons why deployment of the bit would be beneficial in > ways that are

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

Tim Wicinski writes: > Following up on Petr's suggestion that the "DNSEC Transparency" mechanism is > documented > and somewhat tested.  FYI, the new version (-04) that I just published hopefully clarifies better why this draft is useful with or without DNSEC Transparency. DNSSEC Transparency

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

Hi Joe, Sorry for the delay (Paul and I did a bit of back and forth with text changes that took a bit longer, but made it better!) > This draft needs a more compelling problem statement, and a clear description > of why other controls > (e.g. reputational, contractual) are insufficient.

[DNSOP] I-D Action: draft-pwouters-powerbind-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 : The DELEGATION_ONLY DNSKEY flag Authors : Paul Wouters Wes Hardaker

Re: [DNSOP] Validating responses when following unsigned CNAME chains...

On Apr 30, 2020, at 2:31 PM, Michael StJohns wrote: > Because an attacker can twiddle with a CNAME. So while the recipient sees a > CNAME pointing at a validatable end item, that may not have been the end name > the publisher provided. I'd probably say unsecure though, as I don't expect >

Re: [DNSOP] Validating responses when following unsigned CNAME chains...

On 4/30/2020 11:15 AM, Ted Lemon wrote: On Apr 29, 2020, at 8:01 PM, Michael StJohns > wrote: If you've got an securely insecure (e.g. delegation was to an insecure zone at some point) CNAME that points into a secure zone, I would say your result is probably

Re: [DNSOP] Fun with draft-pwouters-powerbind

Hi, there: Here's a supporting voice from transparency-land (I co-chair the trans working group). DNSSEC was the first application outside the PKI for which there was interest in developing a CT-like auditable log, but some obvious questions about scope and scalability have stalled the work.

Re: [DNSOP] Validating responses when following unsigned CNAME chains...

On Apr 30, 2020, at 12:00 PM, Brian Somers wrote: > I would say RFC 4035 sections 4.2 and 4.3 say this. Section 5.5 re-iterates > that > SERVFAIL should be sent if signatures don’t validate. Yes, now that I read it with that in mind I see that you are correct. Thanks!

Re: [DNSOP] Validating responses when following unsigned CNAME chains...

On Apr 30, 2020, at 8:17 AM, Ted Lemon wrote: > > On Apr 29, 2020, at 11:38 PM, Brian Somers wrote: >> Furthermore, the CNAME alias RRset must be validated unless the CD bit is >> set. >> A validating resolver MUST validate and can only return RRsets if they are >> proven >> to be either

[DNSOP] Fw: New Version Notification for draft-mglt-dnsop-dnssec-validator-requirements-09.txt

Hi, Please find a new version of "Recommendations for DNSSEC Resolvers Operators". We restructured the text according to the feed backs we received during the Singapore meeting. We especially clarified where the trust is for an operator when it relies on the software provider for the update of

Re: [DNSOP] Validating responses when following unsigned CNAME chains...

On Apr 29, 2020, at 11:38 PM, Brian Somers wrote: > Furthermore, the CNAME alias RRset must be validated unless the CD bit is set. > A validating resolver MUST validate and can only return RRsets if they are > proven > to be either insecure or secure. If the aliased RRset is bogus, the answer

Re: [DNSOP] Validating responses when following unsigned CNAME chains...

On Apr 29, 2020, at 8:01 PM, Michael StJohns wrote: > If you've got an securely insecure (e.g. delegation was to an insecure zone > at some point) CNAME that points into a secure zone, I would say your result > is probably Bogus or Unsecure as you haven't any way to evaluate trust. I > don't

Re: [DNSOP] Validating responses when following unsigned CNAME chains...

On Apr 29, 2020, at 8:01 PM, Shumon Huque wrote: > > On Wed, Apr 29, 2020 at 7:30 PM Ted Lemon > wrote: > The question is, if the stub resolver can validate, and has been asked to > validate, in that case what do we do if the CNAME is not in a secure zone? > Your

Re: [DNSOP] Validating responses when following unsigned CNAME chains...

On Thu, Apr 30, 2020 at 5:39 AM Vladimír Čunát wrote: > On 4/30/20 2:01 AM, Shumon Huque wrote: > > It definitely can't set the AD bit. So, I suppose your argument is why > > bother authenticating the target. That's a defensible question. [...] > > Certainly not defensible. The AD bit isn't the

Re: [DNSOP] New draft on delegation revalidation

> I meant servers within the child (or parent) NS set had different NS > sets configured in them, i.e. yet another level of mismatch. Maybe > that's not worth investigating, but I'm pretty sure I've come across > such misconfigurations in the past. Oh now I get it. We did only with a sample of

Re: [DNSOP] Validating responses when following unsigned CNAME chains...

On 4/30/20 2:01 AM, Shumon Huque wrote: > It definitely can't set the AD bit. So, I suppose your argument is why > bother authenticating the target. That's a defensible question. [...] Certainly not defensible.  The AD bit isn't the only part.  What if the CNAME target is spoofed (BOGUS) or

Re: [DNSOP] Validating responses when following unsigned CNAME chains...

On Thursday, 30 April 2020 02:12:15 UTC Shumon Huque wrote: > ... > > Deployed validator code says Insecure. It can't be Bogus, because the > validator has determined that the CNAME is a demonstrably insecure zone, +1. -- Paul ___ DNSOP mailing

Re: [DNSOP] Privacy and DNSSEC

On Wednesday, 29 April 2020 15:54:33 UTC Shumon Huque wrote: > to the list, after Paul Wouters replied to me privately. > > I realize now this was Paul W responding to Paul V. I thought in > my response below I was replying again to Paul V! ah. too many pauls, as before. nevertheless i agreed

Re: [DNSOP] Privacy and DNSSEC

On Wednesday, 29 April 2020 13:44:12 UTC Shumon Huque wrote: > On Wed, Apr 29, 2020 at 12:49 AM Paul Vixie wrote: > > ... > > This is by no means a problem unique to DNSSEC. Many new protocol features > have and continue to face the middlebox challenge: SCTP, TCP fast open, > multi- > path TCP,