Re: [DNSOP] [Ext] Do we need new draft that recommends number limits ?

The DNS needs operational profile documents. Documents that set societal norms for the global public Internet while still allowing the protocol to be overly flexible ("my network, my rules" world). On 3/12/24, 04:19, "DNSOP on behalf of Kazunori Fujiwara" wrote: With DNS, there are

Re: [DNSOP] [Ext] About key tags

On 3/1/24, 13:45, "pch-b538d2...@u-1.phicoh.com on behalf of Philip Homburg" wrote: >If we have a protocol where validators are allowed to discard RR sets with >duplicate key tags but we place no restriction on signers, then we have a >protocol with a high chance of failure even if

Re: [DNSOP] [Ext] About key tags

On 3/1/24, 11:13, "pch-b538d2...@u-1.phicoh.com on behalf of Philip Homburg" wrote: I removed a lot of logic, as it seems dead on. But... >This would allow validators to reject any DS or DNSKEY RR set that has a >duplicate key tag. "This" refers to barring keys from having duplicate

Re: [DNSOP] [Ext] About key tags

From: DNSOP on behalf of Shumon Huque Date: Wednesday, February 28, 2024 at 16:22 To: Edward Lewis Cc: John Levine , "dnsop@ietf.org" Subject: Re: [DNSOP] [Ext] About key tags >… I think writing a BCP telling folks how to avoid collisions would make sense >though (and yes, i

Re: [DNSOP] [Ext] About key tags

On 2/27/24, 17:09, "DNSOP on behalf of John Levine" wrote: >The kind of load is different but in each case the client needs to >limit the amount of work it's willing to do. We can forbid it in the >protocol but unless you have better contacts at the Protocol Police >than I do,

Re: [DNSOP] Detecting, regeneration and avoidance was Re: [Ext] About key tags

On 2/20/24, 16:35, "Mark Andrews" wrote: >Validator resource consumption (CPU) *is* is tied to tags. The number of tag collisions is related but is not the only cause of the validator resource consumption vulnerability. >Without tags the cost of verification increases and the number of cache

Re: [DNSOP] Detecting, regeneration and avoidance was Re: [Ext] About key tags

From: DNSOP on behalf of Bob Harold Date: Tuesday, February 20, 2024 at 09:53 To: Edward Lewis Cc: "dnsop@ietf.org" , Paul Wouters Subject: Re: [DNSOP] Detecting, regeneration and avoidance was Re: [Ext] About key tags >But if I have a 'standby' DS record, to allow faster roll

Re: [DNSOP] Detecting, regeneration and avoidance was Re: [Ext] About key tags

impediment to having it be the rule that key hash collisions aren't allowed. Like, I'm not saying there aren't problems, but this is not an insurmountable problem. On Tue, Feb 20, 2024 at 9:41 AM Edward Lewis mailto:edward.le...@icann.org>> wrote: From: Ted Lemon mailto:mel...@fugue.com

Re: [DNSOP] Detecting, regeneration and avoidance was Re: [Ext] About key tags

From: Ted Lemon Date: Tuesday, February 20, 2024 at 09:05 To: Edward Lewis Cc: Mark Andrews , Paul Wouters , "dnsop@ietf.org" Subject: Re: [DNSOP] Detecting, regeneration and avoidance was Re: [Ext] About key tags >This seems like an implementation detail. I don’t want to b

[DNSOP] Detecting, regeneration and avoidance was Re: [Ext] About key tags

On 2/16/24, 15:05, "DNSOP on behalf of Mark Andrews" wrote: Pardon ... perhaps this issue has died down, but I've been off a few days, and I just saw this... >Generating a new key is not hard to do. That's not the issue, it's knowing that it would be the wise thing to do that is the issue.

[DNSOP] On suffering ... Re: [Ext] About key tags

On 2/16/24, 11:13, "DNSOP on behalf of Petr Špaček" wrote: > should resolvers suffer from more complex code & work, or should signers > suffer if they do something very unusual? Coming from this perspective, find a solution may be difficult. At the core, the DNS is extremely flexible, overly

Re: [DNSOP] [Ext] About key tags

On 2/15/24, 13:03, "DNSOP on behalf of Ralf Weber" wrote: >... key collisions should not be allowed. The problem with this statement is that you can't prevent them in advance. So long as we have a short-hand means for referring to a key, you run this risk. And if someone sees an advantage in

Re: [DNSOP] [Ext] About key tags

On 2/15/24, 12:49, "Wellington, Brian" wrote: >A fairly simple way to deal with this issue is a Flag Day. As Ralf said in a >later post, the number of zones with colliding key tags is relatively small. >It would certainly be reasonable to declare that at some time in the future, >colliding

Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions

From: Ben Schwartz Date: Wednesday, February 14, 2024 at 11:34 To: Edward Lewis , Manu Bretelle Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions > For the "testing" flag, the

Re: [DNSOP] [Ext] About key tags

On 2/15/24, 04:37, "DNSOP on behalf of Petr Špaček" wrote: >If you think colliding keys should be allowed, please propose your own limits >for sensible behavior. I will take popcorn and watch. Hmmm, key tags were intended to simplify computation, somehow it seems that they've gone the other

Re: [DNSOP] [Ext] About key tags

The reason this topic is on the list now isn't validation, it began as a key management issue. Donald's right (of course) in what he now posted. But the performance gain of sub-selecting keys based on key tag is less than originally anticipated and comes at the cost of confusion in key

Re: [DNSOP] [Ext] About key tags

On 2/14/24, 10:14, "DNSOP on behalf of Yorgos Thessalonikefs" wrote: >(actively while validating) to 4. Recent data shared in dns-oarc showed >mainly 2 collisions observed in the wild and we thought 4 is a safe number. That's certainly reasonable given the reality we live in. If any

Re: [DNSOP] [Ext] About key tags

On 2/14/24, 10:10, "DNSOP on behalf of Paul Hoffman" wrote: >On Feb 14, 2024, at 01:39, Petr Špaček wrote: >> In my mind this is good enough reason to outlaw keytag collisions - > without them it would be _much_ easier to implement reasonable limits without > risk of breaking

Re: [DNSOP] [Ext] About key tags

On 2/14/24, 09:00, "Havard Eidnes" wrote: Not arguing, but to tease out the difficulty of all this: >One is to line up the signers "behind each other", so that the second one >signs an already-signed-by-the-first-signer zone... The issue is in deciding the order they are lined up. In one

Re: [DNSOP] [Ext] About key tags

On 2/14/24, 08:54, "Petr Špaček" wrote: >How many keytag collisions are you willing to allow & at the same time > protect validators from 2023-50387? Admitting to reading the CVE link after replying: the issue doesn't need there to be a collision between keys. I could tie up validation

Re: [DNSOP] [Ext] About key tags

On 2/14/24, 08:38, "DNSOP on behalf of Joe Abley" wrote: >Is the triggering incident not just another cautionary note that we learn > from? That was my original thought. I don't mean my thought has changed, but that's the reason I bothered to raise this. >Why is this particular

Re: [DNSOP] [Ext] About key tags

On 2/14/24, 04:40, "DNSOP on behalf of Petr Špaček" wrote: >In my mind this is good enough reason to outlaw keytag collisions - >without them it would be _much_ easier to implement reasonable limits >without risk of breaking legitimate clients. That would make key tags meaningful.

Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions

From: Manu Bretelle Date: Tuesday, February 13, 2024 at 19:03 To: Edward Lewis Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions First - why am I resisting this proposal? I believe that fo

Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions

of thought one might have had!) From: Ben Schwartz Date: Monday, February 12, 2024 at 16:39 To: Manu Bretelle , Peter Thomassen Cc: Edward Lewis , "dnsop@ietf.org" Subject: Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions Manu and

[DNSOP] Adding a URL ... Re: [Ext] Re: About key tags

I should have included this URL, pointing to the article (via Google Translate) saying the outage was rooted in a key tag collision... https://www.rbc.ru/technology_and_media/07/02/2024/65c38fea9a794752176bd3a0 On 2/12/24, 08:50, "Edward Lewis" wrote: On 2/9/24, 20:37, &

Re: [DNSOP] Encourage by the operator ... Re: [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions

On 2/9/24, 11:02, "pch-b538d2...@u-1.phicoh.com on behalf of Philip Homburg" wrote: > One of the misconceptions in DNSSEC is that the zone administrator > is in control of the situation, dictating the state of signing, > the cryptography in use, and so on. DNSSEC is for the benefit

Re: [DNSOP] [Ext] Re: About key tags

On 2/9/24, 22:05, "Mark Andrews" wrote: >The primary use of the key tag is to select the correct key to validate the >signature from multiple keys. Yes - which is great if 1) you need to pare down the potential set of keys into something you can handle (like, from 10's to 3) and 2) if you

Re: [DNSOP] [Ext] Re: About key tags

On 2/9/24, 20:37, "Wellington, Brian" wrote: >The behavior was never added into any standards document because it has >nothing to do with the standard. True - but still it created a situation where operators could get snagged on something. >If an implementation doesn’t support multiple keys

[DNSOP] Encourage by the operator ... Re: [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions

On 2/8/24, 09:25, "DNSOP on behalf of Philip Homburg" wrote: >whether fallback to NS/DS is encouraged by the operator of the zone. > >If DELEG is mainly used to signal that a secure transport, such as DoT, DoH, >or DoQ, is available then falling back to NS/DS might be preferred (by the >zone

[DNSOP] About key tags

Prior to the news breaking that having two keys with the same key tag in a TLD led to an outage in late January, I was debugging some analysis code of mine that broke when a different TLD simultaneously published two DNSKEY resource records with the same key tag. This code had been fixed once

Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions

From: Manu Bretelle Date: Wednesday, February 7, 2024 at 14:19 To: Peter Thomassen Cc: Edward Lewis , Ben Schwartz , "dnsop@ietf.org" Subject: Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions >Agreed, I don't think that

Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions

reaction. The discussion was focused only on seeing multiple implementations, falling short of examining whether anyone made us of the code (paths). Deployment to me is how the field of operations grades a protocol definition. On 2/1/24, 07:49, "DNSOP on behalf of Peter Thomassen&qu

Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions

attack, in the past protocol definitions have been written as if everything unexpected was malicious. The question remains - can a receiver distinguish between a benign error and a malicious attack? From: Ben Schwartz Date: Tuesday, January 30, 2024 at 13:59 To: Edward Lewis , "dnsop@iet

Re: [DNSOP] Two points by Joe - was Re: [Ext] Re: DELEG and parent only resolution

On 1/31/24, 13:04, "DNSOP on behalf of Dave Lawrence" wrote: > >Edward Lewis writes: >> The impact on the registration system wasn’t raised at the table. > >Not entirely true. We did recognize that there'd need to be an EPP >draft too. Ah, yes. J

[DNSOP] Two points by Joe - was Re: [Ext] Re: DELEG and parent only resolution

Two things buried in Joe’s message I want to build on: From: DNSOP on behalf of Joe Abley Date: Wednesday, January 31, 2024 at 03:17 > >However, that will require new metadata to be bundled with domain registration >in transactions between registrant and registrar and between registrar and

[DNSOP] General comment about downgrades vs. setting expectations in protocol definitions

I hear talk about "downgrade attacks" frequently, across different ideas. Hearing it again in the context of DELEG, I had this thought. We often wind up mired in discussions about downgrades, what they mean, the consequences. I'd suggest, as definers of protocols, we think in terms of

[DNSOP] Conflicting info was - Re: [Ext] Re: draft-dnsop-deleg-00

On 1/30/24, 09:57, "DNSOP on behalf of Roy Arends" wrote: >> On 30 Jan 2024, at 12:57, Joe Abley wrote: > >> Related, what to do when the ipv4hints are not the same as the > corresponding A RRSet? > >IMHO, potential unsigned glue records from elsewhere are inferior to > address

[DNSOP] Extensible from the start - was - Re: [Ext] Re: DNSOPComments on draft-dnsop-deleg-00.txt - section 1

On 1/30/24, 01:14, "DNSOP on behalf of Ralf Weber" wrote: >... but having a >record type that is extensible from the start ... Designing in extensibility is a very good idea, ah, essential idea, but isn't a no-brainer. Start by asking and documenting: What information is needed at a DNS

[DNSOP] Comments on draft-dnsop-deleg-00.txt - Section 3

# 3. Implementation ... # 3.1. Including DELEG RRs in a Zone # #A DELEG RRset MAY be present at a delegation point. The DELEG RRset #MAY contain multiple records. DELEG RRsets MUST NOT appear at a #zone's apex. # #A DELEG RRset MAY be present with or without NS or DS RRsets

[DNSOP] Comments on draft-dnsop-deleg-00.txt - section 2

As I'm not writing code, my comments will be less detailed... # 2. DELEG Record Type ... # 2.1. Difference between the records # #This document uses two different resource record types. Both records #have the same functionality, with the difference between them being #that the

[DNSOP] Comments on draft-dnsop-deleg-00.txt - section 1

I won't be pedantic (nits, wording) this time around, just raise conceptual issues in section 1 # 1. Introduction # #In the Domain Name System [STD13], subdomains within the domain name #hierarchy are indicated by delegations to servers which are #authoritative for their portion of

[DNSOP] Comments on draft-dnsop-deleg-00.txt - abstract

Being clear on the motivation for taking on the development and eventual deployment of DELEG is important to carry this work forward. I'll start with some pedantic observations about the abstract: #Abstract # # A delegation in the Domain Name System (DNS) is a mechanism that # enables

Re: [DNSOP] [Ext] Re: Automated delegation management via DDNS

On 10/25/23, 12:19 PM, "DNSOP on behalf of Johan Stenstam" wrote: >Of course you have to agree that “push” is a better mechanism than “pull” when >it comes to propagating information about a change in one end to the other end. Perhaps pulling this entirely out of context, but I'm not sure I

[DNSOP] NXDOMAIN and NoError/NoData was Re: [Ext] Compact DoE sentinel choice

>Note however that Cloudflare quite deliberately implemented this differential >behavior (to preserve NXDOMAIN visibility for pre DNSSEC clients I suspect). >Some other implementations of Compact DoE return a uniform (NOERROR) RCODE for >either case. The trouble I have, thinking about the

Re: [DNSOP] [Ext] Compact DoE sentinel choice

>… I do want to point out that Compact DoE handles wildcards quite differently, >and this may not be readily apparent to the casual observer. FWIW, I noticed. (Not meaning to say “I’m not a casual observer” but…). This is something that was playing in my mind when reviewing the proposal. In

Re: [DNSOP] [Ext] Compact DoE sentinel choice

>Compact DoE, and RFC4470 already appear to violate it for ENT responses. And >it was (arguably) already violated by >pre-computed NSEC3 (5155), where an empty non-terminal name (or rather the >hash of it) does solely own an >NSEC3 record. NSEC3 is different. Because NSEC3 hashes the labels

Re: [DNSOP] [Ext] Compact DoE sentinel choice

On Mon, Jul 31, 2023 at 11:58 AM Edward Lewis mailto:edward.le...@icann.org>> wrote: >You've probably stumbled across Cloudflare's differential behavior for DO=0 vs >DO=1 queries. With non-DNSSEC queries it provides a vanilla, unsigned >NXDOMAIN response. With DNSSEC enabled queri

Re: [DNSOP] [Ext] Compact DoE sentinel choice

On 7/28/23, 1:48 PM, "DNSOP on behalf of Viktor Dukhovni" wrote: >We rolled out NSEC3 by introducing new algorithm code points, and >eventually these weere widely enough deployed to allow zones to be >signed with 7/8/10/13/14 without being seen as insecure by a significant >

Re: [DNSOP] [Ext] what could we do with 15 unused bits of QDCOUNT?

On 7/26/23, 4:11 PM, "DNSOP on behalf of George Michaelson" wrote: > >if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in >the header. I don't think you can repurpose them. One concern is backwards compatibility - code in place now wouldn't understand. The practice

Re: [DNSOP] [Ext] Compact DoE sentinel choice

On 7/24/23, 1:55 PM, "DNSOP on behalf of Viktor Dukhovni" wrote: >2. That said, there are multiple ways to *distinguish* ENT vs. NXDOMAIN >responses: > >a. Sentinel RTYPE for NXDOMAIN with just NSEC + RRSIG for ENT. >b. Sentinel RTYPE for ENT with just NSEC

[DNSOP] Early comments on https://www.ietf.org/archive/id/draft-thomassen-dnsop-generalized-dns-notify-01.txt

After a quick read of Generalized DNS Notifications, -01, I have some comments: It would be ludicrous of me to argue against the notion that event driven approaches are superior to polling approaches. However, event driven approaches require more design work which is why it is natural for

Re: [DNSOP] [Ext] Coming soon: WG interim meeting on the definition of "lame delegation"

On 6/21/23, 4:46 PM, "DNSOP on behalf of Robert Edmonds" wrote: >"In-bailiwick" vs. "out-of-bailiwick" I think the topic is no longer important. But I'll explain why I brought up "bailiwick" in this context. Bailiwick, according to a (non-technical/natural language dictionary, such as

Re: [DNSOP] [Ext] Coming soon: WG interim meeting on the definition of "lame delegation"

I’ve just come across this message (I have been out a bit recently)…sorry is this is late. These are suggestions… For the situation where a (an active) nameserver is not configured to answer a query it received (which is the case where my use of lame delegation comes from), I’d suggest the

Re: [DNSOP] [Ext] Re: Coming soon: WG interim meeting on the definition of "lame delegation"

From: DNSOP on behalf of Vladimír Čunát Date: Tuesday, June 20, 2023 at 6:01 AM To: "dnsop@ietf.org" Subject: [Ext] Re: [DNSOP] Coming soon: WG interim meeting on the definition of "lame delegation" >On 19/06/2023 17.00, Masataka Ohta wrote: >>I can't see any problem with "lame" delegation

Re: [DNSOP] [Ext] Re: rfc8499bis: lame

On 6/8/23, 11:23 PM, "DNSOP on behalf of Bob Bownes -Seiri" wrote: >I would posit that the potential to view the word as offensive has increased >as language usage has changed in the intervening years since it was first used >in this context. Researching a now-abandoned draft on the origin

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

On 5/11/23, 7:30 PM, "DNSOP on behalf of Mark Andrews" wrote: > >It’s not a challenge to track what is lame. It’s dead simple. You just > have to look. Getting >it addressed is the challenge. Speaking from experience (which means I'm about to launch an amplification attack here:

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

On 5/4/23, 5:08 AM, "DNSOP on behalf of Mark Delany" wrote: > >I have one last question. Regardless of whether we agree precisely on what > "lame" means, >what is the call to action when a zone or its name servers are declared > lame? > >And how is that different from any other form

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

On 5/1/23, 12:43 PM, "DNSOP on behalf of Wessels, Duane" wrote: >My preferred definition is the one originally given by Paul Vixie, amended > by myself, and further amended by Peter Thomassen: > >A lame delegation is said to exist when one or more authoritative >servers designated

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

On 5/1/23, 4:25 PM, "DNSOP on behalf of Mark Delany" wrote: >On 01May23, John Kristoff apparently wrote: >> (usually due to a bad configuration) > >Was any "lame" situation defined which wasn't the result of a bad > configuration? The difference between observing a symptom and

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

On 5/1/23, 12:58 PM, "DNSOP on behalf of John Kristoff" wrote: On Mon, 1 May 2023 16:09:23 + Paul Hoffman wrote: > It would be grand if a bunch more people would speak up on this > thread. I'm not particularly satisfied with the requirement that there must be a

Re: [DNSOP] [Ext] Meaning of lame delegation

On 4/17/23, 5:18 PM, "DNSOP on behalf of Wes Hardaker" wrote: >I'm not saying that some people don't understand it. It's just a weird >english choice that we're sticking with because of history. ... There are lots of "weird English choices" in play. Consistency is most important, especially

Re: [DNSOP] [Ext] Meaning of lame delegation

On 4/3/23, 4:02 PM, "DNSOP on behalf of Wessels, Duane" wrote: > >(1) NS.EXAMPLE.ORG resolves to an IP address. Queries to the IP address > result in a REFUSED, SERVFAIL, upward referral, or some other indication the > name server is not configured to serve the zone. > >(2)

Re: [DNSOP] [Ext] Working Group Last Call for aft-ietf-dnsop-dnssec-bcp

On 8/2/22, 11:02 AM, "DNSOP on behalf of Paul Hoffman" wrote: >I would rather mention NSEC/NSEC3 so the reader gets an idea for the mechanism >in RFC 8198. I left off NSEC3 because I thought that basically all use of >NSEC3 was with opt-out, but if I'm wrong, I could put it in the text. Just

Re: [DNSOP] The DO bit - was Re: [Ext] Re: signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)

On 7/29/22, 10:49 AM, "DNSOP on behalf of Paul Wouters" wrote: > I would have expected (and have taught) that this was by design to not > disrupt systems with new data unless we knew they were ready for it. I didn’t > realize we first tried to do it without that  This response made me think a

[DNSOP] The DO bit - was Re: [Ext] Re: signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)

On 7/29/22, 3:53 AM, "Petr Špaček" wrote: >By any chance, do you remember in what iteration the DO=1 in query was >introduced? I wonder what sort of disruption was anticipated/feared. > >In hindsight is seems that DO=1 requirement for "new" behavior (like, >say, adding RRSIG to

Re: [DNSOP] [Ext] Re: signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)

On 7/26/22, 3:05 PM, "DNSOP on behalf of Petr Špaček" wrote: >Interesting history lesson, thank you. >Can you elaborate on > > therefore only one can be signed. >please? >What is the reasoning behind it? There were a few iterations in the development of DNSSEC. RFC 4033-4035 are the

Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-algorithm-update

A few follow ups: On 4/14/19, 22:35, "DNSOP on behalf of Mark Andrews" wrote: >You don’t publish DS records (or trust anchors) for a algorithm until the >incoherent state is resolved (incremental signing with the new algorithm is >complete). While that makes sense, the protocol can't

Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-algorithm-update

I've been inactive a long time, but someone alerted me to this message. (Apologies what below looks like it's from a ranting lunatic. But it is.) On 4/12/19, 11:31, "DNSOP on behalf of Mark Andrews" wrote: Well given that the actual rule is all the algorithms listed in the DS RRset

Re: [DNSOP] [Ext] Re: Last Call: (DNS Terminology) to Best Current Practice

Here we go with a thread on the set of Domain Names being a superset of host names again. ;) On 8/14/18, 09:09, "DNSOP on behalf of Tony Finch" wrote: Viktor Dukhovni wrote: > > Indeed in a non-public network, I'm free to provision a > ".1" TLD, and even create hosts as

Re: [DNSOP] [Ext] Re: Comments on draft-wessels-dns-zone-digest-02

My reason for replying to this thead is to say that “we have other solutions in place for this, why one more?” On 8/13/18, 16:43, "DNSOP on behalf of Brian Dickson" mailto:dnsop-boun...@ietf.org> on behalf of brian.peter.dick...@gmail.com> wro >While it

Re: [DNSOP] [Ext] Re: Comments on draft-wessels-dns-zone-digest-02

On 8/13/18, 13:35, "John R Levine" wrote: >Hey, I have a great idea. We could make sure that the zone file received >matches the zone file sent by including a hash of the zonee in a record in the >zone. Whaddaya think? In some sense, it's re-inventing the wheel. >I realize you

Re: [DNSOP] [Ext] Re: Comments on draft-wessels-dns-zone-digest-02

On 8/13/18, 11:50, "John Levine" wrote: >As we may have mentioned once or twice before in this discussion, it lets you >do zone transfers over insecure channels and batch verify the zone before >using it. Yes, I see that. As in no more argument is needed to convince me of that. >but the

Re: [DNSOP] [Ext] Re: Comments on draft-wessels-dns-zone-digest-02

On 8/11/18, 10:44, "DNSOP on behalf of John Levine" wrote: >The way that ZONEMD is defined in the draft, it's not very useful if the >ZONEMD record isn't signed. That's my read too, which is why I question the incremental benefit over relying on DNSSEC while doing the query/response over port

Re: [DNSOP] [Ext] Re: Comments on draft-wessels-dns-zone-digest-02

On 8/9/18, 20:24, "DNSOP on behalf of Paul Wouters" wrote: >The point was to allow redistribution and to not depend on a trusted source That, FWIW, is the heart of DNSSEC. Source authentication and data integrity for data sets is the advertised goal (as well as provable non-existence) of the

[DNSOP] Comments on draft-wessels-dns-zone-digest-02

FWIW, this message was spurred by this comic strip [yes, today as I write]: http://dilbert.com/strip/2018-08-09. "Will the time taken to generate and verify this record add to the security of a zone transfer?" I understand that there is no protection for cut point or glue records now, nor any

Re: [DNSOP] [Ext] Re: zonemd/xhash versus nothing new

On 8/1/18, 07:29, "DNSOP on behalf of Tony Finch" wrote: >I was kind of assuming that the NSEC chain would include the glue - >obviously delegations and glue in opt-out intervals are not protected at >all. The reason cut point information is not signed is that the copies are not authoritative,

Re: [DNSOP] [Ext] Re: Ghost of a zone signature effort from the long ago days...

On 7/31/18, 15:25, "DNSOP on behalf of Wessels, Duane" wrote: >Olafur wrote a little about this a couple weeks ago. He said: Oh, okay, never mind me then. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Ghost of a zone signature effort from the long ago days...

I hear there are proposals to sign the entire contents of zones. zonemd/xhash in some subject lines. (Forgive me if SIG(AXFR) was mentioned before...) "Domain Name System Security Extensions", a'la RFC 2065, section 4.1.3 Zone Transfer (AXFR) SIG: "However, to efficiently assure the

Re: [DNSOP] [Ext] Re: [Doh] [Driu] Resolverless DNS Side Meeting in Montreal

I caught wind of this in my DNSOP folder...(cutting down the reply a *little* bit) On 7/11/18, 04:23, "DNSOP on behalf of Petr Špaček" wrote: > On 10.7.2018 20:57, Ryan Sleevi wrote: > > > > > > On Tue, Jul 10, 2018 at 2:09 PM, Mike Bishop> > wrote:

Re: [DNSOP] [Ext] Lameness terminology

example. On 5/4/18, 11:53, "Paul Hoffman" <paul.hoff...@vpnc.org> wrote: On 4 May 2018, at 8:16, Edward Lewis wrote: > FWIW, if one is to cite a definition of lame, I'd use "Common DNS > Operational and Configuration Errors", February 1996, aka RF

Re: [DNSOP] [Ext] Lameness terminology

On 5/4/18, 05:59, "DNSOP on behalf of Shane Kerr" wrote: >Pending Ed's archival research, it seems like we need to actually do some work to structure the concepts around lameness. Digging in... Quick and dirty, using a

Re: [DNSOP] Lameness, registries, and enforcement was Re: [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

On 5/4/18, 10:26, "DNSOP on behalf of Joe Abley" wrote: > from the perspective of whom? There's issue 6 for you. I included that in issue 3. Reference the "yadda, yadda, yadda". [https://en.wikipedia.org/wiki/The_Yada_Yada] I

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

Just noticed this (and why terminology is a problem): On 5/3/18, 17:25, "Mark Andrews" wrote: >Start removing lame delegation ... Are we talking about "lame servers" or "lame delegations"? If the latter, is a "delegation" a single NS / glue record or a the set of NS records

[DNSOP] Lameness, registries, and enforcement was Re: [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

This isn't about terminology but the once-again debate about a registry's responsibility here. It's simple to state a policy that says: If an registered NS record does not function properly, the registrant will be notified and the NS record will be removed from the DNS until such time that it

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

On 4/23/18, 10:23, "DNSOP on behalf of Shane Kerr" wrote: >I don't know if this is documented anywhere so that it can be >referenced properly, sorry. I am happy to discuss further but I think >this basically covers all I

Re: [DNSOP] [Ext] Re: tdns, 'hello-dns' progress, feedback requested

On 4/13/18, 15:02, "DNSOP on behalf of Matthew Pounsett" wrote: >On 13 April 2018 at 11:11, bert hubert wrote: >>RFC 1034, 4.3.2, step 3, a. It says to go back to step 1, which means that in

[DNSOP] "Trustworthiness" - was Re: [Ext] Re: tdns, 'hello-dns' progress, feedback requested

On 4/13/18, 13:51, "DNSOP on behalf of Mukund Sivaraman" wrote: >Nod, RFC 2181 doesn't use RFC 2119/8174 keywords, so the "should" there >doesn't have a pointy meaning. In "Clarifications to the DNS Specification" (the title of RFC

[DNSOP] Comments on draft-ietf-dnsop-kskroll-sentinel-11

1. ##which they are generated. The Key Tag is a 16-bit value computed ##from the RDATA portion of a DNSKEY RR using a formula similar to a ##ones-complement checksum. RRSIG RRs contain a Key Tag field whose Suggest a reference to the section where the formula is defined, lest the

[DNSOP] Conflict between "Aggressive Use" and "Wildcards"

A few weeks ago, I came across a blog post describing a "security hole" in so-called "NSEC Aggressive Use" implementations. https://medium.com/nlnetlabs/the-peculiar-case-of-nsec-processing-using-expanded-wildcard-records-ae8285f236be After some exchanges of email with the blog author, I

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

>Filename: draft-ietf-dnsop-kskroll-sentinel-05.txt Why is this written in a way that the mechanism only applies to the root zone? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Re: KSK-Sentinal: Once more down the naming rathole.

On 2/21/18, 14:59, "DNSOP on behalf of Wessels, Duane" wrote: >> On Feb 21, 2018, at 2:53 PM, Joe Abley wrote: >> >> Why did 8145 specify hex? I don't remember the discussion. >I argued

[DNSOP] Why new code/old keys? Re: [Ext] Re: sentinel and timing?

On 2/8/18, 01:02, "DNSOP on behalf of Paul Wouters" wrote: >We have a giant hole in our understanding of why there are update nameservers >running the latest software with the older keys. If just to spread rumors, I heard the following as early as November, 2016. One of the issues is that

[DNSOP] WGLC session-state-signal comments

(Due to weirdness with email, the WGLC announcement for me came on DNSSD and not DNSOP. Shoulder shrug - something to debug for later.) I was told of this last call: referring to the document at https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-05 Overall - the approach looks

[DNSOP] is the root special? (musings of an old timer) - was Re: [Ext] Re: Making draft-ietf-dnsop-kskroll-sentinel apply to all zones

On 12/15/17, 11:34, "DNSOP on behalf of Joe Abley" wrote: >That seems fair. I was definitely speaking from a set of personal assumptions >without any data; it's certainly possible that non-root trust anchors are >widely deployed, however

Re: [DNSOP] [Ext] Re: Call for Adoption: draft-huston-kskroll-sentinel

A couple of reactions to this message: On 11/27/17, 10:10, "DNSOP on behalf of Richard Barnes" wrote: > [one] should know better than to claim that a mechanism that requires > resolver updates will have "immediate benefit" :) I have been

[DNSOP] One review of draft-huston-kskroll-sentinel-04.txt

A review of: https://tools.ietf.org/html/draft-huston-kskroll-sentinel-04 This is not a blow-by-blow, nit picking review, but tries to dive into archtecture level issues: 1. I don't think the Root Zone should be specifically called out, this mechanism ought to work for any domain name. The

[DNSOP] Comments on mic comments, 5011 update's authorship

...From listening to the recording of the meeting on Monday, Nov 13,2017: It seems that there is an impression that I feel the authors of the 5011-update draft are wrong choice to be documenting this. This is not meant to be a personal attack on the authors but a blanket comment on seeing

Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record

To begin...thanks, Frederico, I was trying to find that case but had forgotten which ccTLD was involved. (Web searches failed me...) On 11/14/17, 23:11, "DNSOP on behalf of Paul Wouters" wrote: >On Wed, 15 Nov 2017, Frederico A C Neves

Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record

On 11/13/17, 21:15, "DNSOP on behalf of Paul Wouters" wrote: >> I'm not sure that the need for robustness outweighs the expectation of >> someone explicitly adding a trust anchor anymore. >But that’s not your call to make, but the call of

Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record

On 11/9/17, 12:48, "DNSOP on behalf of Evan Hunt" wrote: >On Thu, Nov 09, 2017 at 03:48:26PM +0100, Petr Špaček wrote: >> Nice write-up Edward! You have nicely summarized why Mark and me agree >> that validator should use longest

  1   2   3   4   5   >