Re: [DNSOP] Privacy and DNSSEC

On Wednesday, 29 April 2020 01:17:04 UTC Shumon Huque wrote: > ... > > Paul - I guess I'm missing some background here. In what sense did > getting DS working throw validating stubs overboard? Do you mean it > took the focus away from them? no. i mean that the decision to require a "clear path"

Re: [DNSOP] New draft on delegation revalidation

On Tue, Apr 28, 2020 at 5:43 AM Giovane C. M. Moura wrote: > Hi Shumon, > > > Do you plan to maintain the parent/child disjoint NS > > domain (marigliano.xyz ) going forward? And what > > about the test > > domains for other types of misconfigurations? > > Great idea. Let

Re: [DNSOP] Privacy and DNSSEC

On Tue, Apr 28, 2020 at 12:06 AM Paul Vixie wrote: > On Tuesday, 28 April 2020 01:02:27 UTC Shumon Huque wrote: > > On Sat, Apr 25, 2020 at 2:57 AM Paul Vixie wrote: > > > ... > > > > The DNSSEC specs have always contemplated validating stub resolvers. > > I think the Kaminsky cache poisoning

[DNSOP] Fun with draft-pwouters-powerbind

I did a little greppage on gTLD zone files, and found 93,000 signed A and records, most of which appear to be stale glue, except for some that look deliberate. I think we will find that the assumption that TLD zone files are delegation-only does not hold up very well in practice, so I am

Re: [DNSOP] Client Validation - filtering validation?

On Tuesday, 28 April 2020 21:57:16 UTC John Levine wrote: > In article <6.2.5.6.2.20200428121847.081a2...@elandnews.com> you write: > >I found a WG draft (expired) from 2017 about RPZ. I am not sure why > >it stalled in DNSOP. There is also a 2018 draft (expired). I > >vaguely recall looking at

Re: [DNSOP] Client Validation - filtering validation?

In article <6.2.5.6.2.20200428121847.081a2...@elandnews.com> you write: >I found a WG draft (expired) from 2017 about RPZ. I am not sure why >it stalled in DNSOP. There is also a 2018 draft (expired). I >vaguely recall looking at a draft. However, proposed changes were >not accepted. One

Re: [DNSOP] Call for Adoption: draft-pusateri-dnsop-update-timeout

On Tue, 28 Apr 2020, Wes Hardaker wrote: We are looking for *explicit* support for adoption. I support it, though I'd feel more comfortable hearing from operators that want to deploy it. I suspect there are many, but that's just suspicion. I think you really mean IPAM vendors? Like is this

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

Joe Abley writes: > On Apr 27, 2020, at 18:28, Wes Hardaker wrote: > > > Thanks for the comments. I'm working on a more clear rewrite of the > > introduction. I'd love your feedback on it once I get it wrapped up. > > Yes, for sure! Happy to do that. Half done. Either tonight or tomorrow.

Re: [DNSOP] Call for Adoption: draft-pusateri-dnsop-update-timeout

Tim Wicinski writes: > We are looking for *explicit* support for adoption. I support it, though I'd feel more comfortable hearing from operators that want to deploy it. I suspect there are many, but that's just suspicion. -- Wes Hardaker USC/ISI

Re: [DNSOP] Client Validation - filtering validation?

Hi Paul, At 06:38 AM 28-04-2020, Paul Wouters wrote: There is only one method where you can trust the filtering service. That is that they offer you the filtered data in a neutralized fashion. I have already been waiting a few years for the RPZ draft to pass the ISE publication process so the

[DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-07.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 : Message Digest for DNS Zones Authors : Duane Wessels Piet Barber

Re: [DNSOP] Call for Adoption: draft-pusateri-dnsop-update-timeout

Hi Tim, On 27 Apr 2020, at 14:28, Tim Wicinski wrote: > As we stated in the meeting and in our chairs actions, we're going to run > regular call for adoptions over next few months. > We are looking for *explicit* support for adoption. > > > This starts a Call for Adoption for

Re: [DNSOP] Call for Adoption: draft-pusateri-dnsop-update-timeout

Mark thanks for the feedback on implementation. This knowledge helps in the adoption process. if other software folks have opinions on implementation yes/no the chairs would like to hear. tim On Mon, Apr 27, 2020 at 6:24 PM Mark Andrews wrote: > > > > On 28 Apr 2020, at 04:28, Tim Wicinski

Re: [DNSOP] If DNSSEC signatures do not validate ...

> > Davey - if there is a pervasive/omnipresent man-in-the-middle attacker, > then no security protocol (DNSSEC, TLS, HTTPS or any other) can > _prevent_ the attack. All they can do is to _detect_ that an attack is > taking > place (and probably abort). > > Shumon. > Fair enough. Davey >

Re: [DNSOP] If DNSSEC signatures do not validate ...

On Tue, Apr 28, 2020 at 11:22 AM Paul Wouters wrote: > On Tue, 28 Apr 2020, Davey Song wrote: > > > OK. It make sense to try every name servers to defend the case if the > adversary only intercept one path. But the adversary also know the resolver > will > > retry other servers. So a smarter

Re: [DNSOP] If DNSSEC signatures do not validate ...

On Tue, 28 Apr 2020, Davey Song wrote: OK. It make sense to try every name servers to defend the case if the adversary only intercept one path. But the adversary also know the resolver will retry other servers. So a smarter adversary may intercept in the aggregated upstreaming path where all

Re: [DNSOP] If DNSSEC signatures do not validate ...

That language could probably use some clarification. I would interpret > "if .. none of the RRSIGs can be validated" as "if .. none of the RRSIGs > can be validated from _any_ of the authority servers". In practice, every > validating resolver I'm familiar with will retry other servers upon >

Re: [DNSOP] If DNSSEC signatures do not validate ...

On Tue, Apr 28, 2020 at 9:48 AM Davey Song wrote: > > I think you mean if you receive a BOGUS validation result (eg missing >> RRSIG records, or otherwise are not getting the records needed for proof >> of non-existance or signatures. In that case, I think the existing >> DNS protocol already

Re: [DNSOP] If DNSSEC signatures do not validate ...

> I think you mean if you receive a BOGUS validation result (eg missing > RRSIG records, or otherwise are not getting the records needed for proof > of non-existance or signatures. In that case, I think the existing > DNS protocol already tells you to try other servers? > According to RFC4035

Re: [DNSOP] Minutes for 23 April 2020 Interim

Dear Paul, On Mon, Apr 27, 2020 at 3:51 AM Paul Wouters wrote: > On Thu, 23 Apr 2020, Tim Wicinski wrote: > > > We've uploaded the minutes from today's session > > Thanks for the minutes. One comment on the GOST comment from Jim: > > > Jim: Supports work > Wants references to old

Re: [DNSOP] Client Validation - filtering validation?

On Tue, 28 Apr 2020, Vittorio Bertola wrote: I've been thinking about whether/how a provider of filtering service (directly or indirectly) could be explicitly trusted to provide filtered "answers". There is only one method where you can trust the filtering service. That is that they offer

Re: [DNSOP] If DNSSEC signatures do not validate ...

On Tue, 28 Apr 2020, Davey Song wrote: As far as I know, in DNSSEC the validating resolver is able to identify a Bad response if signatures do not validate. But it unable to retrieve the good one for stub resolver if there are other alternatives.  I think you mean if you receive a BOGUS

[DNSOP] If DNSSEC signatures do not validate ...

Hi folks, As far as I know, in DNSSEC the validating resolver is able to identify a Bad response if signatures do not validate. But it unable to retrieve the good one for stub resolver if there are other alternatives. I'm thinking about a draft proposal if signatures do not validate, the

Re: [DNSOP] Client Validation - filtering validation?

> Il 28/04/2020 04:34 Brian Dickson ha > scritto: > > I've been thinking about whether/how a provider of filtering service > (directly or indirectly) could be explicitly trusted to provide filtered > "answers". > >From time to time, I've also been thinking that something like this

Re: [DNSOP] New draft on delegation revalidation

Hi Shumon, > Do you plan to maintain the parent/child disjoint NS  > domain (marigliano.xyz ) going forward? And what > about the test > domains for other types of misconfigurations? Great idea. Let me look into this, will get back to with that. > Did you look at the