Subject: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-bootstrap-validator-00.txt

From: Joe Abley <[email-masked]>
Date: Mon, 19 Mar 2018 15:14:37 +0000

Hi all,

This draft from 2011 emerged blinking into the sunlight from the grave where it expired, growling something about KSK rollovers and brains. Dave and I promptly wrestled it to the ground and locked it in the datatracker where we can safely poke sticks at it through the reinforced metal bars.

The original draft contained this prescient language:
   The possibility remains, however, that [RFC5011] signalling will not
   be available to a validator: e.g. certain classes of emergency KSK
   rollover may require a compromised KSK to be discarded more quickly
   than [RFC5011] specifies, or a validator might be off-line over the
   whole key-roll event.

   This document provides guidance on how DNSSEC Validators might
   determine an appropriate set of trust anchors to use at start-up, or
   when other mechanisms intended to allow key rollover to be tolerated
   gracefully are not available.
Dave and I imagine this kind of thinking might be relevant and timely. Tim and Suz have kindly tolerated my increasingly frantic handwaving on this subject and have offered me some minutes in the dnsop meeting tomorrow, where I intend to suggest that a specification along these lines is necessary and that the working group should take this on.

Joe

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-jabley-dnsop-bootstrap-validator-00.txt
> Date: 19 March 2018 at 14:59:53 GMT
> To: "Joe Abley" <[email-masked]>, "Dave Knight" <[email-masked]>
> 
> 
> A new version of I-D, draft-jabley-dnsop-bootstrap-validator-00.txt
> has been successfully submitted by Joe Abley and posted to the
> IETF repository.
> 
> Name:		draft-jabley-dnsop-bootstrap-validator
> Revision:	00
> Title:		Establishing an Appropriate Root Zone DNSSEC Trust Anchor at Startup
> Document date:	2018-03-19
> Group:		Individual Submission
> Pages:		9
> URL:            https://www.ietf.org/internet-drafts/draft-jabley-dnsop-bootstrap-validator-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-jabley-dnsop-bootstrap-validator/
> Htmlized:       https://tools.ietf.org/html/draft-jabley-dnsop-bootstrap-validator-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-jabley-dnsop-bootstrap-validator
> 
> 
> Abstract:
>   Domain Name System Security Extensions (DNSSEC) allow cryptographic
>   signatures to be used to validate responses received from the Domain
>   Name System (DNS).  A DNS client which validates such signatures is
>   known as a validator.
> 
>   The choice of appropriate root zone trust anchor for a validator is
>   expected to vary over time as the corresponding cryptographic keys
>   used in DNSSEC are changed.
> 
>   This document provides guidance on how validators might determine an
>   appropriate trust anchor for the root zone to use at start-up, or
>   when other mechanisms intended to allow key rollover to be tolerated
>   gracefully are not available.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: tjw ietf <[email-masked]>
Date: Mon, 19 Mar 2018 15:31:09 +0000

I will say that I tolerate Joe's hand waving, I can't speak for my
co-chair.

On Mon, Mar 19, 2018 at 3:14 PM, Joe Abley <[email-masked]> wrote:

> Hi all,
>
> This draft from 2011 emerged blinking into the sunlight from the grave
> where it expired, growling something about KSK rollovers and brains. Dave
> and I promptly wrestled it to the ground and locked it in the datatracker
> where we can safely poke sticks at it through the reinforced metal bars.
>
> Dave and I imagine this kind of thinking might be relevant and timely. Tim
> and Suz have kindly tolerated my increasingly frantic handwaving on this
> subject and have offered me some minutes in the dnsop meeting tomorrow,
> where I intend to suggest that a specification along these lines is
> necessary and that the working group should take this on.
>
>
> Joe
>
> Begin forwarded message:
>
> *From: [email-masked]
> *Subject: **New Version Notification for
> draft-jabley-dnsop-bootstrap-validator-00.txt*
> *Date: *19 March 2018 at 14:59:53 GMT
> *To: *"Joe Abley" <[email-masked]>, "Dave Knight" <
> [email-masked]>
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>

---

From: Matthew Pounsett <[email-masked]>
Date: Mon, 19 Mar 2018 15:21:11 -0400

On 19 March 2018 at 11:14, Joe Abley <[email-masked]> wrote:

> I won't be in the correct country top attend tomorrow's meeting, so I'll
state here that I think this is useful work.

I've done a quick perusal of the document and so far I've got one
question:   do you really mean to use the word "stub" in the definition of
"Validator"?  The way you're using Validator in the document, it doesn't
seem to me that it's actually limited to stub resolvers, and should include
all validating resolvers.