Re: [DNSOP] [art] draft-ietf-dnsop-attrleaf

Howdy. (I posted this on the ART list, yesterday, because Tim started a query about attrleaf there, but the note should probably also be posted at the attleaf hosting wg list. /d) I've been mulling over the challenges of this registration topic for more than a decade, constantly being

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

On Thu, Aug 3, 2017 at 11:49 PM, Michael StJohns wrote: > I answered the question that you asked. > Yes, thanks Mike. That answers my question about the attack. It was not clear that pre-published was synonymous with stand-by keys. > Other people are weighing in on

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 > wrote: On

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

Hi Mike, On Thu, Aug 3, 2017 at 10:47 PM, Michael StJohns wrote: > 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

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] Emergency KSK Rollover for locally secure zones.

On Thu, Aug 3, 2017 at 10:06 PM, Wessels, Duane wrote: > > > On Aug 3, 2017, at 12:58 PM, Aanchal Malhotra wrote: > > > > However, I still don't see how it would help in case of trust anchor/KSK > compromise. > > This is why I wrote "I don't know if you

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

> On Aug 3, 2017, at 12:58 PM, Aanchal Malhotra wrote: > > However, I still don't see how it would help in case of trust anchor/KSK > compromise. This is why I wrote "I don't know if you consider it a solution." Even so, I think it could be useful, depending on the nature

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

Hi Duane, Thanks for pointing to RFC 8145. It's a very nice mechanism to allow zone administrators to know the status of key rollover in the DNSSEC signed zone to take further decisions. However, I still don't see how it would help in case of trust anchor/KSK compromise. With RFC 8145, the zone

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

On Thu, Aug 3, 2017 at 3:01 PM, Aanchal Malhotra wrote: > Hi Scott, > > Thanks for the response. I have another question in that case. Please see > below. > > > On Thu, Aug 3, 2017 at 6:17 PM, Rose, Scott wrote: >> >> Hi, >> >> (800-81 author here) >> >>

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

Hi Scott, Thanks for the response. I have another question in that case. Please see below. On Thu, Aug 3, 2017 at 6:17 PM, Rose, Scott wrote: > Hi, > > (800-81 author here) > > That needs to be updated as it was from the earlier revision of 800-81. It > really should

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

Hello Aanchal, I don't know if you consider this a solution, but you may want to take a look at RFC 8145, aka "Signaling Trust Anchor Knowledge." Per this RFC, validators can convey trust anchor contents to zone operators via periodic queries. By looking at the signal data you can see how

Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error

At Sat, 29 Jul 2017 14:27:57 +0100, Tony Finch wrote: > > - One possible idea of another extended error code: one that indicates > > a type-ANY query is responded with just one type of RRset when there > > can be more. > > Note that it is almost always the case that ANY

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

Hi, (800-81 author here) That needs to be updated as it was from the earlier revision of 800-81. It really should stress the use of RFC 5011 automated trust anchor update process. The first version of the doc assumed RFC 5011 was not available in the majority of implementations, which is

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

Dear all, May be this has been discussed long ago on the list or elsewhere. Please guide me to proper pointers, if any. Section 11.2.1 in [1] states the following for KSK rollover for *locally secure zones*: "*In