Re: [DNSOP] [Ext] Notification Call for Adoption: draft-bash-rfc7958bis

After reading the thread, I'm confused as to why there's any question as to adoption.  This is an independent submission replacing an independent submission, and is directive only on ICANN and explanatory for everyone else. Section 5 has "This document describes how DNSSEC trust anchors for

Re: [DNSOP] should all ccTLD be on the Public Suffix list?

On 7/18/2023 8:42 PM, George Michaelson wrote: I know, I could submit these to the PSL website directly. I am asking a meta question: do we think that operationally, if a PSL exists, that all ccTLD and TLD should be on it? The following ccTLD are in ISO3166 but not in the PSL: bd bl bq

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review

On 8/19/2022 3:30 PM, Paul Hoffman wrote: DNS resolvers that serve the DNS protocol and non-DNS protocols at the same time MUST resolve .alt names using the non-DNS protocols. It was written the current way as a way to alert developers who are using the Locally-Served DNS Zones registry

[DNSOP] Authorship - was: Re: [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt

On 8/15/2022 12:17 PM, Wes Hardaker wrote: Paul Wouters writes: This is why I also think 8624bis is better than a stand-alone document, as it takes into account security effects, market deployment, and trying to push the deployments to where we want it to go, instead of just issuing a

Re: [DNSOP] Call for Adoption: Negative Caching of DNS Resolution Failures

Disregard this - it was targeted for a different adoption call. Thanks to Paul H for noticing. Mike On 7/12/2022 12:51 PM, Michael StJohns wrote: On 7/12/2022 9:54 AM, Tim Wicinski wrote: This starts a Call for Adoption for Negative Caching of DNS Resolution Failures The draft

Re: [DNSOP] Call for Adoption: Survey of Domain Verification Techniques using DNS

Let's try and attach the comment to the right call... *sigh*.  See below. On 7/12/2022 9:29 AM, Tim Wicinski wrote: This starts a Call for Adoption for Survey of Domain Verification Techniques using DNS The draft is available here:

Re: [DNSOP] Call for Adoption: Negative Caching of DNS Resolution Failures

On 7/12/2022 9:54 AM, Tim Wicinski wrote: This starts a Call for Adoption for Negative Caching of DNS Resolution Failures The draft is available here: https://datatracker.ietf.org/doc/draft-dwmtwc-dnsop-caching-resolution-failures/ Please review this draft to see if you think it is

Re: [DNSOP] Fwd: Working Group Last Call for draft-ietf-dnsop-rfc5933-bis

On 7/10/2022 12:30 PM, Dmitry Belyavsky wrote: Section 10: " Sorry, didn't get :( I hope this helps - Mike Oops.  My fault, and I never went back to expand on the omission. Basically, section 10 has TBA1 and TBA2 for two code points, but you use actual values for your

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-06.txt

paragraph are poorly constructed. Later, Mike On 7/8/2022 8:49 AM, Bob Harold wrote: On Thu, Jul 7, 2022 at 6:21 PM Michael StJohns wrote: On 7/7/2022 5:32 AM, Willem Toorop wrote: Dear dnsop, This draft describes a mechanism for automatic provisioning of zones among author

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-06.txt

On 7/7/2022 5:32 AM, Willem Toorop wrote: Dear dnsop, This draft describes a mechanism for automatic provisioning of zones among authoritative name servers by way of distributing a catalog of those zones encoded in a regular DNS zone. The version's focus was finalizing for Working Group Last

Re: [DNSOP] [Ext] DNSOP Document Adoption Poll (June 2022)

Hi Benno - On 7/7/2022 3:12 PM, Benno Overeinder wrote: Hi Mike, On 07/07/2022 20:26, Michael StJohns wrote: On 7/7/2022 12:28 PM, Benno Overeinder wrote: Conducting a survey (2 times now) has worked well over the past 1.5 years to prioritise finishing existing work and starting new work

Re: [DNSOP] [Ext] DNSOP Document Adoption Poll (June 2022)

Hi Benno - On 7/7/2022 12:28 PM, Benno Overeinder wrote: Hi Mike, On 07/07/2022 17:21, Michael StJohns wrote: On 7/7/2022 11:10 AM, Benno Overeinder wrote: It helps us and the WG itself to prioritise WG activities and start a regular WG call for adoption of a number of documents.  We

Re: [DNSOP] [Ext] DNSOP Document Adoption Poll (June 2022)

Hi Benno - On 7/7/2022 11:10 AM, Benno Overeinder wrote: Hi Paul, On 07/07/2022 16:58, Paul Hoffman wrote: On Jul 7, 2022, at 6:49 AM, Benno Overeinder wrote: Gentle reminder, the poll runs until July 9. Can you say how the poll will be used? There was pretty strong push-back after the

Re: [DNSOP] punctuation follies, I-D Action: draft-ietf-dnsop-alt-tld-15.txt

On 6/27/2022 4:31 PM, John Levine wrote: It appears that Michael StJohns said: I suggest that reserving "_*" names is redundant as (I *think* - I didn't go looking for the reference?) strings beginning with an underscore can only be used in left-most components of a DNS name. Dunno

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-15.txt

Folks - It's either time to put a stake through the heart of this DNS vampire that rises from the grave every 6 months, or to push it for publication.  Given that in 8 years it has yet to gain enough traction for publication, perhaps we de-adopt the draft back into the caring hands of its

Re: [DNSOP] punctuation follies, I-D Action: draft-ietf-dnsop-alt-tld-15.txt

On 6/27/2022 4:05 PM, John Levine wrote: It appears that Peter Thomassen said: I am proposing to reserve all top-level underscore labels (_*) for special use. Why? While I don't think that reserving underscore names will break anything that is not already broken, I also don't see what

Re: [DNSOP] DNSOP Document Adoption Poll (June 2022)

On 6/27/2022 11:29 AM, Ted Lemon wrote: I think your instinct is correct, Tim. It’s not an optimization to bypass discussion as part of a call for adoption. By asking us to consider six drafts at once, and discuss none of them, you create a strong likelihood of insufficient review. +1 - the

Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

In line: On 5/1/2022 1:41 PM, John Levine wrote: It appears that Mukund Sivaraman said: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. By way of this, by removing the names of authors, isn't the copyright notice attributed to

Re: [DNSOP] [Ext] Fwd: Working Group Last Call for draft-ietf-dnsop-rfc5933-bis

On 4/14/2022 5:09 PM, Paul Hoffman wrote: On Feb 1, 2022, at 12:35 PM, Tim Wicinski wrote: We were reviewing the Working Group Last Call for this, and we received no comments. We know there was interest in at least moving this forward, but even Warren concurred we can't send this to the

Re: [DNSOP] Fwd: Working Group Last Call for draft-ietf-dnsop-rfc5933-bis

On 2/1/2022 3:35 PM, Tim Wicinski wrote: All We were reviewing the Working Group Last Call for this, and we received no comments.  We know there was interest in at least moving this forward, but even Warren concurred we can't send this to the IESG unless there are folks saying they feel it

Re: [DNSOP] SVCB/HTTPS weasel words are dangerous.

On 11/1/2021 11:58 AM, Eric Orth wrote: The important part for preserving compatibility with potential future changes is the "recipients MUST ignore any SvcParams that are present" part. I don't understand what would be different if the record sender SHOULD became a MUST.  Recipients

Re: [DNSOP] SVCB/HTTPS weasel words are dangerous.

On 11/1/2021 11:58 AM, Eric Orth wrote: The important part for preserving compatibility with potential future changes is the "recipients MUST ignore any SvcParams that are present" part. I don't understand what would be different if the record sender SHOULD became a MUST.  Recipients

Re: [DNSOP] Question on interpretation of DO and CD

Hi EKR  - Your table looks correct and hope. You may want to take a look at section 5.9 of RFC 6840, as well as appendix B as there's some implementation guidance with respect to the setting of the CD bit. Mike On 10/6/2021 7:47 PM, Eric Rescorla wrote: Hi folks, We've been trying to

Re: [DNSOP] DNSOPMoving forward on draft-ietf-dnsop-private-tld

g 1, 2021 at 6:04 PM Michael StJohns <mailto:m...@nthpermutation.com>> wrote: Actually, maybe there should be a general document "DNS Squatting Considered Harmful"? I think that we (well, mainly ICANN) already have a large amount that says things along these lines. S

Re: [DNSOP] DNSOPMoving forward on draft-ietf-dnsop-private-tld

Actually, maybe there should be a general document "DNS Squatting Considered Harmful"?   I personally don't see any real difference between squatting on "onion" vs squatting on "zz" except that we ended up with a ex post facto approval of .onion.   And that AIRC was a near thing. So maybe:

Re: [DNSOP] IETF meeting prep and what

looked up, and that mostly doesn't describe the IOT side of things. Later, Mike On 1 Jul 2021, at 05:26, Michael StJohns wrote: Peter et al - It might be useful to review RFC 4986 - https://www.rfc-editor.org/rfc/rfc4986.html - Requirements Related to DNS Security Trust Anchor Rollover - to under

Re: [DNSOP] IETF meeting prep and what

Peter et al - It might be useful to review RFC 4986 - https://www.rfc-editor.org/rfc/rfc4986.html - Requirements Related to DNS Security Trust Anchor Rollover - to understand what the problem requirements were/are before resurrecting this discussion again.   If the requirements have changed,

Re: [DNSOP] Review of draft-ietf-dnsop-rfc5011-security-considerations-13, was Re: [Ext] IETF meeting prep and what

On 6/18/2021 7:11 PM, Paul Wouters wrote: Section 6.1.7 confuses me a bit as it defines a numResolvers variable, and uses that to calculate an acceptable new timing period. To me it feels that number of resolvers should not matter, as we should stick to the formal time where all resolvers are

Re: [DNSOP] [Ext] IETF meeting prep and what

On 6/18/2021 6:32 PM, Paul Hoffman wrote: On Jun 18, 2021, at 2:21 PM, Wes Hardaker wrote: Peter van Dijk writes: I propose replacing rfc5011-security-considerations I keep meaning to republish it with Olafur's suggested reduced title (since it's really describing just one problem). But

Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-nsec-ttl

On 2/3/2021 2:31 PM, Paul Hoffman wrote: On Jan 29, 2021, at 9:31 AM, Michael StJohns wrote: I can't support this as Standards track even though it purports to update standards as it doesn't actually specify an implementable protocol. Basically, this is dependent upon humans doing

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-nsec-ttl

On 1/29/2021 10:22 AM, Tim Wicinski wrote: All After a quick check with the other chairs, we're ready to move this draft forward. This starts a Working Group Last Call for draft-ietf-dnsop-nsec-ttl Current versions of the draft is available here:

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-10.txt

On 9/23/2020 9:11 PM, Donald Eastlake wrote: Hi, Replying on just one point: On Mon, Sep 21, 2020 at 2:27 PM Michael StJohns wrote: ... 2.2.4 - SHA384 has a hash length of 48 bytes. 12 bytes seems to imply some sort of left or right truncation. Show stopper! Explain how this value

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-10.txt

WG review.  2.2.4 is the one that I would have problems with the most. Mike On 9/21/2020 2:26 PM, Michael StJohns wrote: 1.4.4 - "has not been modified." -> "has not been modified between origination and retrieval." 2.2.2 - "MUST be implemented" -

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-10.txt

1.4.4 - "has not been modified." -> "has not been modified between origination and retrieval." 2.2.2 - "MUST be implemented" -> "SHOULD be implemented.  Failure to implement this scheme without other standardized schemes being specified may result in a receiver being unable to validate the

Re: [DNSOP] Question regarding RFC 8499

On 7/23/2020 1:38 PM, Joe Abley wrote: I do appreciate that STD 13 mentions "master" in some cases as a synonym for "primary"; however, it doesn't mention them in a couple with "slave" and I think this is an example of where low-numbered RFCs sometimes need to be read in their historical

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

On 6/14/2020 5:53 PM, Paul Wouters wrote: On Sun, 14 Jun 2020, Michael StJohns wrote: That said, I'd prefer it if the document selected a few (<=10) codes from these ranges so that filtering may be built into various servers and clients to prevent leakage. Then you would expect

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

Roy et al - Is there a document from ICANN taking a position on the assignment of TLDs based on  ISO3166 assignments? When Jon was doing this he was adamant about following their lead - rather than having to make political decisions about what was a country.  The main role he had was not

Re: [DNSOP] Second Working Group Last Call for: Message Digest for DNS Zones

h general benefit nor does it provide a standard and programmatic answer to "what do I do if it doesn't verify", but I'm no longer adamant it needs to be experimental as it no longer forces a contract for future digesting models. Later, Mike On 3/9/2020 5:24 PM, Michael StJohns wrot

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 <mailto:m...@nthpermutation.com>> 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

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

On 4/29/2020 5:50 PM, Ted Lemon wrote: Is there an RFC or draft that talks about what the right thing is to do when an unsigned CNAME points to a record in a signed zone? That is, suppose we are doing validation. The CNAME doesn’t validate, because it’s not signed. When we look up the record

Re: [DNSOP] Second Working Group Last Call for: Message Digest for DNS Zones

On 3/9/2020 4:46 PM, Wessels, Duane wrote: Michael StJohns pointed out (Feb 25) that a verifier that does not recognise a particular ZONEMD Scheme and/or Hash Algorithm may be unable to create the required placeholders, and therefore unable to perform a verification using any (Scheme,Algorithm

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-04.txt

On 2/27/2020 12:46 PM, Wessels, Duane wrote: On Feb 24, 2020, at 7:32 PM, Michael StJohns wrote: An improvement, but still: Thanks Mike. 1.3 - general - add something like "Specifically, ZONEMD covers the integrity of records that are not otherwise covered by DNSSEC". Sorr

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-04.txt

An improvement, but still: 1.3 - general  - add something like "Specifically, ZONEMD covers the integrity of records that are not otherwise covered by DNSSEC". 1.3.5 - "zone digest calculation" not simply "zone digest" - this doesn't require a ZONEMD record. 1.3.2, 1.3.3 and 1.3.4 are

Re: [DNSOP] [Ext] future-proofing (Re: Working Group Last Call for: Message Digest for DNS Zones)

On 1/15/2020 8:39 PM, Paul Hoffman wrote: On Jan 15, 2020, at 5:28 PM, Michael StJohns wrote: I think its a co-existence issue here. I don't think you should have two different (calculation-wise) ZONEMD-like RRSets in the same zone for the reasons you've mentioned. That makes good sense

Re: [DNSOP] [Ext] future-proofing (Re: Working Group Last Call for: Message Digest for DNS Zones)

On 1/15/2020 1:25 PM, Brian Dickson wrote: I don't disagree with the notion of a strong differentiator between ZONEMD and any other digest, either using RRTYPE or with an underscore-prefix name. However, there is a Heisenberg problem, which is that any other digest type needs to be excluded

Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

Thought I'd forgotten about this?  :-) On 1/8/2020 3:13 PM, John R Levine wrote: On Wed, 8 Jan 2020, Michael StJohns wrote: I'm running a private copy of the root zone for my organization. I (automated) check the SOA every so often, and arrange for a download of the zone when it changes.    I

Re: [DNSOP] future-proofing (Re: Working Group Last Call for: Message Digest for DNS Zones)

On 1/8/2020 4:22 PM, Wessels, Duane wrote: On Jan 8, 2020, at 12:20 PM, Paul Vixie wrote: can we please not put the ZONEMD RR at the apex, or else, can we please add an ALG-ID to its rdata. because some day we're going to ship different kinds of MD's, one of which is today's full-zone

Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

On 1/8/2020 2:07 PM, John R Levine wrote: Could you give me a b) for each of these please?   E.g. How does ZONEMD make your life better in each of these and what would happen if you - in a future world - were getting ZONEMD data and validation failed? Unless someone else says they find this

Re: [DNSOP] [Ext] Working Group Last Call for: Message Digest for DNS Zones

On 1/7/2020 10:05 PM, Brian Dickson wrote: My $0.02 on the size issue: I think the onus should be on whoever is publishing a zone with a ZONEMD to provide guidance on what to do if a failure occurs. Similarly, publishers should be sensible on whether to include a ZONEMD based on total size and

Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

On 1/7/2020 6:38 PM, Wessels, Duane wrote: On Jan 6, 2020, at 6:15 PM, Michael StJohns wrote: This specification utilizes ZONEMD RRs located at the zone apex. Non-apex ZONEMD RRs are not forbidden, but have no meaning in this specification. Instead - "non-apex ZONEMD RRs

Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

On 1/7/2020 6:01 PM, Wessels, Duane wrote: On Jan 6, 2020, at 6:15 PM, Michael StJohns wrote: 5) 3.1.2 - This is I believe different than how DNSSEC does it? If it's the same, then this is fine, otherwise this protocol should be calculating the RRSet wire representation the same

Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

On 1/7/2020 5:33 PM, Wessels, Duane wrote: On Jan 6, 2020, at 6:15 PM, Michael StJohns wrote: As I suggested in one of my messages, giving an idea of how long it takes to digest various sizes of zones given commodity hardware would be a good start. Going on and talking about the ratio

Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

On 1/6/2020 9:36 PM, John Levine wrote: In article <7f298591-09b5-dd7c-0dab-afc60def8...@nthpermutation.com> you write: OK.� The point is not to self-approve, but to get a few other non-authors to actually see if they can figure out what you're talking about here and whether they're ever going

Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

On 1/6/2020 6:21 PM, Wessels, Duane wrote: Hello Mike, thanks for the feedback. Hi Duane - On Jan 4, 2020, at 5:14 PM, Michael StJohns wrote: Hi Tim et al - I read through this back a few versions ago and mostly thought it harmless as an experimental RFC. I'm not sure that it's

Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

On 1/6/2020 1:48 PM, John R Levine wrote: Well, OK, here's a concrete example.  I download the COM zone every day from Verisign, and also a separate file with an MD5 hash of the main file.  Using RFC 2119 language, what do I do if the hash I get doesn't match their hash? ... Ok - you've

Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

On 1/6/2020 12:13 PM, John Levine wrote: In article <9952199f-9ea5-2d51-a5d2-6aaf80577...@nthpermutation.com> you write: If a computer can't figure out what to do with a failed validation absent human interaction then you might as well say: "ZONEMD RRs may be safely ignored by all but the

Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

On 1/5/2020 2:00 PM, John Levine wrote: In article <84650844-1d13-9377-c913-23dcbc76d...@nthpermutation.com> you write: 1) A recommendation for the maximum size of the zone (and for that matter the maximum churn rate). This is hinted at in the abstract, but missing from the body of the

Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

Hi Tim et al - I read through this back a few versions ago and mostly thought it harmless as an experimental RFC.  I'm not sure that it's quite ready for prime time as a Standards track RFC. Here's what I think is missing: 1) A recommendation for the maximum size of the zone (and for that

Re: [DNSOP] Consensus suggestion for EDE and the TC bit

On 12/3/2019 5:21 PM, Ralf Weber wrote: Moin! On 3 Dec 2019, at 3:15, Michael StJohns wrote: From 2181:   The TC bit should be set in responses only when an RRSet is required     as a part of the response, but could not be included in its entirety.     The TC bit should not be set merely

Re: [DNSOP] Consensus suggestion for EDE and the TC bit

On 11/21/2019 1:53 AM, Wes Hardaker wrote: During the first DNSOP meeting at IETF 106 there was a discussion that had multiple opinions about what to do with setting the TC bit for EDE information, which is generally supplemental. During my presentation I mentioned that an associate of Viktor

[DNSOP] draft-ietf-dnsop-algorithm-update

Hi - I had someone ask me (last night!!) whether or not the "must sign each RRSet with all of the algorithms in the DNSKEY RRSet" rule applies if the only key with algorithm A in the RRSet has the revoke bit set.  A question I had never previously considered. Given that you can't trace

Re: [DNSOP] KSK rollover choices

On 10/31/2018 2:54 PM, Paul Vixie wrote: Jim Reid wrote: On 31 Oct 2018, at 00:27, Mark Andrews  wrote: Bootstrap is still a issue.  Over fast TA rolling makes it more of a issue. Indeed. And that's the underlying problem that needs to be fixed IMO - for instance when/if there's an

Re: [DNSOP] regarding dnssec-key-timing RFC 7583

Generally, CRLs work reasonably well for revoking intermediate CAs and leaf certificates, not so well for dealing with trust anchors.   CRLs work by the parent signing the revocation (and by being able to re-issue new certificates). Root certs/trust anchors by definition do not have parents.

Re: [DNSOP] Working Group Last Call for for draft-ietf-dnsop-rfc5011-security-considerations-12; was Publication has been requested for draft-ietf-dnsop-rfc5011-security-considerations-12

On 7/10/2018 12:34 PM, Paul Hoffman wrote: On 10 Jul 2018, at 11:35, Michael StJohns wrote: And as you may have guessed I object to the publication of this document on the basis of quality for all the reasons previously stated.  This version of the document is actually in worse shape than

[DNSOP] Working Group Last Call for for draft-ietf-dnsop-rfc5011-security-considerations-12; was Publication has been requested for draft-ietf-dnsop-rfc5011-security-considerations-12

on the changes now, and as well as during the session on Wednesday. Tim On Mon, Jul 9, 2018 at 12:05 PM, Michael StJohns mailto:m...@nthpermutation.com>> wrote: Tim/Suzanne - Please cancel the request for publication until you complete the WGLC for this document. The las

Re: [DNSOP] Publication has been requested for draft-ietf-dnsop-rfc5011-security-considerations-12

/2018 9:08 PM, Michael StJohns wrote: On 7/6/2018 8:13 PM, Tim Wicinski wrote: Tim Wicinski has requested publication of draft-ietf-dnsop-rfc5011-security-considerations-12 as Proposed Standard on behalf of the DNSOP working group. Please verify the document's state at https

Re: [DNSOP] Publication has been requested for draft-ietf-dnsop-rfc5011-security-considerations-12

On 7/6/2018 8:13 PM, Tim Wicinski wrote: Tim Wicinski has requested publication of draft-ietf-dnsop-rfc5011-security-considerations-12 as Proposed Standard on behalf of the DNSOP working group. Please verify the document's state at

Re: [DNSOP] Complexity and innovation in the DNS protocol: the work of DNSOP

On 4/18/2018 5:07 PM, Suzanne Woolf wrote: Second, does this work add significantly to the complexity of the DNS protocol, or the work of implementers and operators? A slight respin of this bullet:  Does this work change the way the infrastructure of the protocol works, or is this work

Re: [DNSOP] On trust anchors, roots of trust, humans and indirection

Sorry its taken me so long to get back to this. On 3/31/2018 7:09 PM, Tony Finch wrote: There are a few pertinent differences between trust anchor witnesses and the undeployed RFC 5011 many-keys setup: * in RFC 5011 each key is completely trusted, whereas no witness is trusted; compromise

Re: [DNSOP] On trust anchors, roots of trust, humans and indirection

be relatively bit-rot resistant (on a system basis) for a design life in excess of 40 years given reasonable attention to administration.  No system related to the DNS can be 100% bit-rot resistant for all clients given the one-way nature of the DNS data flows. More in line. On 3/28/2

[DNSOP] On trust anchors, roots of trust, humans and indirection

Hi - Joe Abley introduced draft-jabley-dnsop-bootstrap-validator [jabbootval] at the DNSOP session this past week.  I was the only (one of the few?) person who suggested that this was a bad idea. Later that week, we ran into each other in the bar and chatted for not long enough to sync, but

Re: [DNSOP] Phishing? was Fwd: nthpermutation

to be something like that Mike On Sun, Mar 25, 2018 at 11:04 PM, Michael StJohns <m...@nthpermutation.com <mailto:m...@nthpermutation.com>> wrote: Apologies for dumping this here, but I figured if anyone had a clue they'd probably be on this list. Is anyone familiar with mo

Re: [DNSOP] 5011-security-considerations status

*pounds head on table*  I'm really not sure how things get worse each time but they appear to. Please, please get rid of activeRefreshOffset, clockskewDriftMargin and retryDriftMargin.    Replace this with a single paragraph noting that the maximum time (assuming no retransmissions) a node

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-10.txt

On 12/20/2017 1:15 PM, Wes Hardaker wrote: Michael StJohns <m...@nthpermutation.com> writes: 1) Drift happens per query. Agreed. I'll go double check that I didn't imply that, or better: make sure I state that in the document. Take it out of any formula.  It has little impact o

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-10.txt

I didn't think this could get worse.  I was wrong. I can't support any version of this document for publication.   In the same way that activeRefreshOffset is a nonsensical value so to are  driftSafetyMargin and timingSafetyMargin. 1) Drift happens per query. 2) Any drift that happens

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt

, those values represent the number of times a client exceeded the calculated safe interval (and divide by the total number of clients to get a percentage...). Later, Mike On 12/15/2017 6:55 PM, Wes Hardaker wrote: Michael StJohns <m...@nthpermutation.com> writes: Below is a java pro

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt

Below is a java program I wrote to model this stuff.  In the table, SF2 represents the number of clients that blew past twice the safety factor (for aR+aHD+aR), SF1 represents the number of clients that blew past the single safety factor.  OF is the number of clients using the

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt

On 12/12/2017 4:03 PM, Wes Hardaker wrote: Michael StJohns <m...@nthpermutation.com> writes: A "perfect" system will behave the way you've described - but adding a safety factor while ignoring the phase shift brought on by retransmits within the addHoldDown interval will

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt

On 12/12/2017 12:24 PM, Wes Hardaker wrote: Michael StJohns <m...@nthpermutation.com> writes: 2) T + activeRefresh  is the time at which the server sees the last query from the last resolver just starting their trust anchor installation. 3) T + activeRefresh + addHoldDownTime is th

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt

On 12/11/2017 8:03 PM, Wes Hardaker wrote: Michael StJohns <m...@nthpermutation.com> writes: Hi Mike, Thanks for explaining your thinking because I think, after reading it: we're actually in agreement but using different terms for where to put in the slop you're worried about. Specif

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt

To try this out, let’s use a ttl of 28 hours and an expiration of 7 days to get an active refresh as below. Take an activeRefresh of 14 hours (giving a fast retry of 2.8 hours and an addHoldDown time of 30 days (720 hour). That gives you an activeRefreshOffset of 6 hours. A perfect resolver

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt

On 12/7/2017 7:53 PM, Wes Hardaker wrote: Michael StJohns <m...@nthpermutation.com> writes: Much improved - but still some disconnects (all review is de novo): That's Mike. All good comments. I've attached responses and actions (or inactions) below and will push a new version s

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt

On 11/29/2017 5:29 PM, Wes Hardaker wrote: 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. FYI, this contains the restructuring talked about during

Re: [DNSOP] 5011-security-considerations and the safetyMargin

On 11/20/2017 11:26 AM, Wes Hardaker wrote: Michael StJohns <m...@nthpermutation.com> writes: 1 something. I think that the consensus is clearly something like that. Are you (MSJ) interested in supplying a suggested final equation for it? Ok - after thinking about it, it tur

Re: [DNSOP] 5011-security-considerations and the safetyMargin

I’m running the math right now to see what works. Give me a few days. Mike On Mon, Nov 20, 2017 at 11:26 Wes Hardaker <wjh...@hardakers.net> wrote: > Michael StJohns <m...@nthpermutation.com> writes: > > > 1 something. > > I think that the consensus is clearly

Re: [DNSOP] 5011-security-considerations and the safetyMargin

1 something. I also believe it should scale as to the size of the subscription base in some way. Basically, this should answer the question of “ given a set of subscribers of size N, a per request failure rate of f, a retry time of R, how long do you have to wait until P% of the subscribers

Re: [DNSOP] Resolver behaviour with multiple trust anchors

On 10/31/2017 4:51 PM, Paul Hoffman wrote: And once again we see the folly of the words "implementation choice" when trying to come up with a coherent DNS. The full quote makes the situation murkier: it is a combination of implementation choice plus configuration options. Some folks on this

Re: [DNSOP] Resolver behaviour with multiple trust anchors

On 10/31/2017 5:39 AM, Moritz Muller wrote: Hi, Together with my colleagues I have been stumbling upon a, for me, unclear case when validating trust anchors. Assuming that a resolver has enabled DNSSEC validation and has the root keys configured. Additionally, it has configured manually a

Re: [DNSOP] Responding to MSJ review of the previous rfc5011-security-considerations

On 10/18/2017 5:21 PM, Wes Hardaker wrote: You said in 4.1: which the principle way RFC5011 is currently being used (even though Section 6 of RFC5011 suggests having a stand-by key available) And then in  T-1 you say: Note that for simplicity we assume

Re: [DNSOP] Responding to MSJ review of the previous rfc5011-security-considerations

Top posting because of the "last call" note. Still not ready. You said in 4.1: which the principle way RFC5011 is currently being used (even though Section 6 of RFC5011 suggests having a stand-by key available) And then in  T-1 you say: Note that for simplicity we assume the

Re: [DNSOP] Working Group Last Call - draft-ietf-dnsop-rfc5011-security-considerations

On 10/18/2017 7:16 AM, tjw ietf wrote: From talking with the authors and reading all the comments on the mailing lists, it appears that all outstanding issues have been addressed. Nice try - but no.  I got Wes' responses yesterday and haven't yet re-read the document (which was published

Re: [DNSOP] Responding to MSJ review of the previous rfc5011-security-considerations

Comments on -05 and your changes in line. On 9/13/2017 1:01 PM, Wes Hardaker wrote: Mike, after your lengthy last review I went through and carefully made sure each of your comments were considered. Most resulted in changes, a few seemed to be just comments and there was nothing to do, and two

Re: [DNSOP] requesting WGLC for 5011-security-considerations

On 9/6/2017 12:05 PM, Wes Hardaker wrote: Matthijs Mekking writes: Thanks for all your points, and I've gone through and handled them all in the text (including discussing that we update 7583 per your request). 2. waitTime only adds one queryInterval, while Itrp adds

Re: [DNSOP] requesting WGLC for 5011-security-considerations

Wes/Warren - you still owe a response on the following. On 7/19/2017 4:42 AM, Michael StJohns wrote: On date time vs intervals - I finally realized why Wes and I are somewhat disconnected on this. 5011 was written as the protocol for the resolver and is totally interval driven.   (E.g

Re: [DNSOP] Emergency KSK Rollover for locally secure zones.

I answered the question that you asked. Other people are weighing in on the root and stand by keys. Mike On 8/3/2017 5:05 PM, Aanchal Malhotra wrote: Hi Mike, On Thu, Aug 3, 2017 at 10:47 PM, Michael StJohns <m...@nthpermutation.com <mailto:m...@nthpermutation.com>> wrote:

Re: [DNSOP] Emergency KSK Rollover for locally secure zones.

On 8/3/2017 3:01 PM, Aanchal Malhotra wrote: A DNSKEY RRset with pre-published KSK is signed by the old (now compromised) KSK. When the resolver uses RFC 5011 for the trust anchor update, the attacker can inject a new KSK (signed by the compromised KSK). Which KSK is now the new T/rust Anchor

Re: [DNSOP] requesting WGLC for 5011-security-considerations

On date time vs intervals - I finally realized why Wes and I are somewhat disconnected on this. 5011 was written as the protocol for the resolver and is totally interval driven. (E.g. query and retry timers are set and fire based on when the resolver performs an action). This document is

Re: [DNSOP] requesting WGLC for 5011-security-considerations

On 7/12/2017 1:35 PM, Wes Hardaker wrote: Mike, The value in 6 regardless of what it is is the wrong value for revocation. revocationPublicationWaitTime is basically EarliestDateAttackFails + queryInterval + slop. Revocations take place immediately. You can delay them only as long as you

Re: [DNSOP] requesting WGLC for 5011-security-considerations

On 7/6/2017 1:40 PM, Wes Hardaker wrote: Michael StJohns <m...@nthpermutation.com> writes: I'm sure you think that... but the small changes you've made to address some of my comments haven't gone far enough. There's also a need for a grammar and syntax pass on the document.

Re: [DNSOP] requesting WGLC for 5011-security-considerations

On 7/5/2017 8:11 PM, Wes Hardaker wrote: Michael StJohns <m...@nthpermutation.com> writes: That's not actually a plus you understand. Mike Sure it is. We're down to the point where large changes aren't needed :-P I'm sure you think that... but the small changes you've made to a

  1   2   >