Subject: [DNSOP] DNSSEC operational issues long term

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Nov 2016 09:46:56 +0100 (CET)

Hi,

today I have discovered something after talking to some people that know 
more than I do.

Example:

I go to the store and buy two DNSSEC enabled devices that rely on DNSSEC 
working for them to work.

I put one device on the network immediately and the other one on the 
shelf. The one I plugged in works just fine for 10 years because it has 
RFC5011 support.

Now after 10 years after plugging the first one in, I take the second one 
off the shelf and plug it in. It will now not work because there has been 
a root zone key rollover. I am told this is by design. This makes me a sad 
panda.

We have a bootstrapping problem. My device has no way to know what time it 
is so it can't verify certificates that might be used to update the key 
material, and by above design decision, DNSSEC doesn't work.

I had some idea that DNSSEC could be used to sign a distribution of 
roughtime (have someone sign a DATE+TIME TXT record so I at least know 
approximately what day and time of day it is), so I could verify 
certificates and then bootstrap myself that way.

I believe that this property of DNSSEC (put on shelf, take from shelf in 
10 years, device now not working properly) is not well known in the wider 
IETF community. Is this documented somewhere in plain text that everybody 
will understand?

What's the current thinking of what a user should do with a device that 
has only old root zone key material? Is there any guidance to vendors on 
what they should instruct users to do in order to make their device 
work again?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Nov 2016 17:54:42 +0900

Why would you put a device on the shelf for ten years?   Is this a
real scenario?   This is certainly a known issue that has been talked
about at length--the conclusion when it was discussed is that there is
nothing we can do about it, and it's relatively unlikely, and manually
fixable.

On Wed, Nov 16, 2016 at 5:46 PM, Mikael Abrahamsson <[email-masked]> wrote:
> I put one device on the network immediately and the other one on the shelf.
> The one I plugged in works just fine for 10 years because it has RFC5011
> support.
>
> off the shelf and plug it in. It will now not work because there has been a
> root zone key rollover. I am told this is by design. This makes me a sad
> panda.
>
> I believe that this property of DNSSEC (put on shelf, take from shelf in 10
> years, device now not working properly) is not well known in the wider IETF
> community. Is this documented somewhere in plain text that everybody will
> understand?
>
> What's the current thinking of what a user should do with a device that has
> only old root zone key material? Is there any guidance to vendors on what
> they should instruct users to do in order to make their device work again?
>
> --
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: George Michaelson <[email-masked]>
Date: Wed, 16 Nov 2016 18:12:52 +0900

I echo what Ted said. If its 'not well known' its a property of the
RFC ecology in general, that things we did know, and did document,
wind up buried in the RFC free text search.

>From memory, the specific issue was discussed across at least two
rounds of IETF, as a thing. I seem to recall Mike St Johns and others
iterating around why we weren't going to be able to design the problem
away.

(btw, if you buy boxes you cannot hand install trust objects into,  I
believe you walked into a problem because 5011 is for documented roll.
It doesn't preclude uncommanded roll which can exist eg if the
california earthquake hits, and all the witnesses die on the west
coast so the east coast HSM is toast and nobody can unlock it so we
replace cold with no sign-over and no signalling opportunity)

IETF documented memory is hard to find. That's true. Things people in
WG know are not widely understood, that's also true. But collectively,
we "do" know this.

-G

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Nov 2016 10:30:56 +0100 (CET)

On Wed, 16 Nov 2016, Ted Lemon wrote:

> Why would you put a device on the shelf for ten years?  Is this a real 
> scenario?  This is certainly a known issue that has been talked about at 
> length--the conclusion when it was discussed is that there is nothing we 
> can do about it, and it's relatively unlikely, and manually fixable.

How is it manually fixable? By someone to ssh into the device and edit a 
file with new key material?

My mom can't do this.

I have personally picked a Cisco AGS out of a unopened box in 2010. By 
then it was probably 15-20 (?) years old?

Anyhow, my takeaway from this message is that DNSSEC can't be used as a 
mechanism for device autoconfiguration. No device trying to autoconfigure 
itself can rely on DNSSEC, because there is a fairly short (few years) 
window for that device to get plugged in, because after that it can't 
autoconfigure itself.

Correct?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Nov 2016 18:33:42 +0900

Or your device needs an RTC...

On Wed, Nov 16, 2016 at 6:30 PM, Mikael Abrahamsson <[email-masked]> wrote:
>> length--the conclusion when it was discussed is that there is nothing we can
>> do about it, and it's relatively unlikely, and manually fixable.
>
>
> I have personally picked a Cisco AGS out of a unopened box in 2010. By then
> it was probably 15-20 (?) years old?
>

---

From: George Michaelson <[email-masked]>
Date: Wed, 16 Nov 2016 18:38:35 +0900

I feel this is a corner case. My experience with 'mom' whitegoods is
that they age out much faster than the 10+ year case. Shops do not
hold electronic goods for sale that long, if its old but unboxed, you
have taken yourself into a dark alley deliberately. If you genuinely
were supporting your mum by buying two, and keeping one offline for 10
years you would have done better buying one, and replacing after 5.

Once you are in a head-space of 'must be old stock compatible' its a
different, not-mum friendly world. Its NASA and you are reading 80
column cards.

Disclosure: I turn my adm-5 lear ziegler terminal on every now and
then, but the flyback transformer whine is painful. I have stock which
exceeds a ten year life but I don't deploy it on anyone I love.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Nov 2016 10:56:35 +0100 (CET)

On Wed, 16 Nov 2016, George Michaelson wrote:

> that they age out much faster than the 10+ year case. Shops do not hold 
> electronic goods for sale that long, if its old but unboxed, you have 
> taken yourself into a dark alley deliberately. If you genuinely were 
> supporting your mum by buying two, and keeping one offline for 10 years 
> you would have done better buying one, and replacing after 5.

Ok, so let me ask an operational question:

The way current root zone key rollovers are thought to be used, what's the 
theoretical shortest worst-case shelf life of a device that relies on 
DNSSEC working for itself to work properly?

So if it's manufactured the day before a new key is publically released, 
when is the key material it has built in no longer viable to have 
successful DNSSEC validation?

---

From: George Michaelson <[email-masked]>
Date: Wed, 16 Nov 2016 19:05:06 +0900

On the current timeline, October 11 ->  January 11 so three months.

Vendors of sealed units who ship equipment from before October 11 with
delivery held up for three months at the docks by a strike, or people
who put the sealed unit into a long-delay orbit to Mars to be turned
on by Matt Damon on arrival have a problem here, if they don't have a
backdoor manual override.

How many vendors do you think are in this space, not shipping a .trx
or other download which installs the new info?

On Wed, Nov 16, 2016 at 6:56 PM, Mikael Abrahamsson <[email-masked]> wrote:
>> I feel this is a corner case. My experience with 'mom' whitegoods is that
>> they age out much faster than the 10+ year case. Shops do not hold
>> electronic goods for sale that long, if its old but unboxed, you have taken
>> yourself into a dark alley deliberately. If you genuinely were supporting
>> your mum by buying two, and keeping one offline for 10 years you would have
>> done better buying one, and replacing after 5.
>
>
> theoretical shortest worst-case shelf life of a device that relies on DNSSEC
> working for itself to work properly?
>
> when is the key material it has built in no longer viable to have successful
> DNSSEC validation?

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Wed, 16 Nov 2016 19:04:47 +0900

> On Nov 16, 2016, at 18:56, Mikael Abrahamsson <[email-masked]> wrote:
> 
> So if it's manufactured the day before a new key is publically released, when is the key material it has built in no longer viable to have successful DNSSEC validation?

Do the first (only) bootstrap without validation if validation fails?

Doing DNSSEC for names pointing to NTP servers (or other time sources) have a similar concern.

Ask

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 16 Nov 2016 11:12:19 +0100

> successful DNSSEC validation?

A properly designed device will discover that its preconfgured trust
anchor differs from what it finds online. It will not trust either
of these but offers the user a way to afind the proper trust anchor.

	jaap

---

From: Jim Reid <[email-masked]>
Date: Wed, 16 Nov 2016 10:23:38 +0000

> On 16 Nov 2016, at 10:12, Jaap Akkerhuis <[email-masked]> wrote:
> 

Or, take the device back to the place where you bought it and ask for your money back (or a replacement) because it doesn't work as intended. Most nations have laws which offer this sort of consumer protection. Good luck with that approach 10 years after the date of purchase though.

Now which box in the attic has my mum's library of VHS tapes? :-)

---

From: Emily Shepherd <[email-masked]>
Date: Wed, 16 Nov 2016 10:38:51 +0000

On Wed, Nov 16, 2016 at 10:56:35AM +0100, Mikael Abrahamsson wrote:
>So if it's manufactured the day before a new key is publically 
>released, when is the key material it has built in no longer viable to 
>have successful DNSSEC validation?

The new KSK was generated at the end of October this year and will be 
published on IANA's website in February / March once it has been 
confirmed to have been successfully imported into their West Coast 
facility.

It will then be published in the root zone in July signed by the old KSK 
and the new key will be used from October 2017 onwards [1]. A 
manufacturer, therefore, should have plenty of warning that they need to 
support the ability to change the root KSK, either through some kind of 
firmware / software upgrade or, preferably, via RFC5011 [2] compliance 
which automates the whole process.

Emily

[1]  ICANN Ltd., "2017 KSK Rollover Operational Implementation Plan",
     July 2016,
     <https://www.icann.org/en/system/files/files/ksk-rollover-operational-implementation-plan-22jul16-en.pdf>

[2]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
     Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
     September 2007, <http://www.rfc-editor.org/info/rfc5011>.

-- 
Emily Shepherd
Computer Science Graduate, MEng (Hons)
W: https://emilyshepherd.me/
M: +44(0)7575 721 231

---

From: Tony Finch <[email-masked]>
Date: Wed, 16 Nov 2016 11:43:25 +0000

Ted Lemon <[email-masked]> wrote:

> Why would you put a device on the shelf for ten years?

The failure occurs if a device is on the shelf for the wrong 6 months
(second half of 2017) and this is a completely reasonable length of time
to hold stock.

> This is certainly a known issue that has been talked about at

It isn't manually fixable by most people.

It *can* be handled automatically.

Your vendor needs to provide one or more statically-configured bootstrap
server IP addresses and non-DNSSEC bootstrap trust anchor(s). The device
can then get the time and trust anchors (e.g. using something like
tlsdate) from the bootstrap server and do whatever other software updates
it needs to when it is unboxed.

In principle it's possible to do a vendor-neutral version, provided there
are some organizations willing to provide some long-term infrastructure.
Each "witness" organization provides a bootstrap time server and key
server, and its own self-signed bootstrap certificate. None of the
witnesses are individually trusted, though! Each witness can only state
its view of the world, which must be distrusted until it is sufficiently
corroborated. A device boostraps trust by observing that a quorum of
witnesses agree. There must be several independent witnesses to provide
resilience against compromise or withdrawal or service.

The bootstrap certs musn't become permanent. Each witness generates a new
key and certificate annually, and distributes the cert out-of-band for use
in new software and configurations. Witnesses can update their bootstrap
server IP address the same way. The old certs and IP addresses continue to
work for as long as possible.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Shannon: West or southwest 5 to 7, occasionally gale 8 later. Rough or very
rough, becoming high. Occasional rain. Good, occasionally moderate.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 16 Nov 2016 13:51:29 +0100

>material, and by above design decision, DNSSEC doesn't work.

Recently, there was some discussion in homenet related to this topic,
in particular how does a device without battery backed RTC obtain the
current time.

I think that ideally this should be discussed in a security related working
group. Because a lot of this is basically how we can have long term stable 
(online) signature keys.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Nov 2016 14:18:17 +0100 (CET)

On Wed, 16 Nov 2016, Philip Homburg wrote:

> Recently, there was some discussion in homenet related to this topic, in 
> particular how does a device without battery backed RTC obtain the 
> current time.
>
> I think that ideally this should be discussed in a security related 
> working group. Because a lot of this is basically how we can have long 
> term stable (online) signature keys.

Ok, so what I see right now is DNSSEC punting the problem somewhere else. 
NTP is punting it somewhere else. TLS is punting it somehere else.

Oh, your DNSSEC key material is too old, use TLS. Oh, your time is not 
accurate, use NTP. Oh you don't have time, use DNSSEC, or TLS, or magic. 
Or just throw away your box, you were stupid to put it on the shelf for 
the wrong 9 months.

As a whole, nobody seems to be interested in actually coming up with a 
viable solution that actually fixes peoples problems. Everybody's just 
punting the problem elsewhere or waving their hands and says "not our 
problem".

---

From: Emily Shepherd <[email-masked]>
Date: Wed, 16 Nov 2016 13:26:53 +0000

On Wed, Nov 16, 2016 at 02:18:17PM +0100, Mikael Abrahamsson wrote:
>Ok, so what I see right now is DNSSEC punting the problem somewhere 
>else. NTP is punting it somewhere else. TLS is punting it somehere 
>else.

I don't think this is what people are saying. The issue of trust anchor 
updates is one that is not unique to DNSSEC, so it makes sense to look 
at some of the solutions other systems which rely on chains of trust 
use. What happens, for example, when a Certificate Authority needs to 
replace its root certificate? 

>accurate, use NTP. Oh you don't have time, use DNSSEC, or TLS, or 
>magic. Or just throw away your box, you were stupid to put it on the 
>shelf for the wrong 9 months.

Again this isn't the exact point that was being made. I believe the 
answer you are referring to is that of consensus. When deciding which 
DNSSEC anchor to trust, if you have multiple sources using a variety of 
different trust anchors, this adds a bit of credibility. Eg if both the 
TLS secured IANA site includes a KSK which has also been signed by 
ICANN's root x509 cert and this has been endorsed by a bunch of trusted 
people with PGP signatures, for example, that becomes a relatively 
difficult thing for an attacker to spoof.

>punting the problem elsewhere or waving their hands and says "not our 

Did you see my original response? Proposals for automatic DNSSEC trust 
anchor updating *do* exist.

Emily

---

From: Dan York <[email-masked]>
Date: Wed, 16 Nov 2016 13:30:46 +0000

On Nov 16, 2016, at 10:18 PM, Mikael Abrahamsson <[email-masked]<mailto:[email-masked]>> wrote:

As a whole, nobody seems to be interested in actually coming up with a viable solution that actually fixes peoples problems. Everybody's just punting the problem elsewhere or waving their hands and says "not our problem".

Do you have a suggestion for a solution?

Dan

--
Dan York
Senior Content Strategist, Internet Society
[email-masked]<mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked]<mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/

---

From: Philip Homburg <[email-masked]>
Date: Wed, 16 Nov 2016 14:38:58 +0100

>anchor updating *do* exist.

Is there any document that deals with the situation where a device has
been in a box for 10 years and then has to bootstrap automatically?

I'm not aware of any. But maybe there is.

Note that by and large such a device has no idea about time. NTP is not 
secure. Any key material stored on the box is no longer valid.

If the answer to DNSSEC bootstrapping is use TLS, then there is still the
question what about time, is the certificate that was stored on the box 
10 years ago still usable.

Are there resolvers (and libraries like getdns) that can transition from
not having any trust anchors to full DNSSEC validation. Do other parts of
the same system see either DNSSEC failures or answers that were not
validated.

---

From: Bob Harold <[email-masked]>
Date: Wed, 16 Nov 2016 08:41:03 -0500

On Wed, Nov 16, 2016 at 8:30 AM, Dan York <[email-masked]> wrote:

>
> On Nov 16, 2016, at 10:18 PM, Mikael Abrahamsson <[email-masked]> wrote:
>
> This is not well thought out, but what jumps to mind is to keep a chain of
signatures in the root DNS that links from the original KSK up through the
current KSK (or at least the last 10 years).  Perhaps a different record
type, so it is only sent if asked for.

Does that make any sense?

-- 
Bob Harold

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 16 Nov 2016 13:44:29 +0000

> As a whole, nobody seems to be interested in actually coming up with a viable solution that actually fixes peoples problems. Everybody's just punting the problem elsewhere or waving their hands and…

I don't think its possible to have a solution that works for devices on the shelf for an arbitrarily long time.  You posed the problem as 10 years, which I think is an unrealistically long time.

You could probably have a useful discussion about what is an appropriate amount of time for something to be on the shelf and still expect it to work.  If there is some consensus on that then the operators of the key material can design around it.  

DW

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 16 Nov 2016 14:54:53 +0100

> I'm not aware of any. But maybe there is.

I remember
<https://tools.ietf.org/html/draft-wijngaards-dnsext-trust-history-03>. At
that time some other proposals were floating around as well.

	jaap

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Nov 2016 15:42:33 +0100 (CET)

On Wed, 16 Nov 2016, Bob Harold wrote:

> This is not well thought out, but what jumps to mind is to keep a chain 
> of signatures in the root DNS that links from the original KSK up 
> through the current KSK (or at least the last 10 years).  Perhaps a 
> different record type, so it is only sent if asked for.
>

Someone told me that the information needed could be gained in replaying a 
root zone packet from every 3 months since when DNSSEC was originally 
developed (or at least from when whatever this proposed solution was 
done).

That seems to be similar to what you're thinking of here. Can we get a 
solution that does that, that isn't a DDOS amplification vector or 
something else hugely problematic?

---

From: Bob Harold <[email-masked]>
Date: Wed, 16 Nov 2016 09:56:35 -0500

Looks like someone else thought of it already:
    https://tools.ietf.org/html/draft-wijngaards-dnsext-trust-history-03

Thanks to Jaap for that info.

Someone will probably point out that using keys for a long time increases
the chances that someone can break them,  But in this case I think it is
worth the risk, to fix this issue.

-- 
Bob Harold
hostmaster, UMnet, ITcom
Information and Technology Services (ITS)
[email-masked]
734-647-6524 desk

On Wed, Nov 16, 2016 at 9:42 AM, Mikael Abrahamsson <[email-masked]>
wrote:

> developed (or at least from when whatever this proposed solution was done).
>

---

From: Tony Finch <[email-masked]>
Date: Wed, 16 Nov 2016 15:33:07 +0000

Wessels, Duane <[email-masked]> wrote:
>
> I don't think its possible to have a solution that works for devices on
> the shelf for an arbitrarily long time.  You posed the problem as 10
> years, which I think is an unrealistically long time.
>
> You could probably have a useful discussion about what is an appropriate
> amount of time for something to be on the shelf and still expect it to
> work.  If there is some consensus on that then the operators of the key
> material can design around it.

Good points.

I think 10 years is definitely ambitious, but we do have multiple existing
points of comparison:

(1) Lifetime of X.509 trust anchors

e.g. www.iana.org (where the DNSSEC root trust anchor is distributed)
has a cert that chains up to the DigiCert High Assurance EV Root CA which
is 10 years old and expires 15 years in the future.

(2) Root DNS server IP addresses

8 of the 13 servers have the same IPv4 address as they had in 1999, which
is plenty for establishing a quorum of witnesses.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Shannon: West 6 to gale 8, perhaps severe gale 9 later. Rough or very rough,
becoming mainly high. Thundery showers. Good, occasionally poor.

---

From: william manning <[email-masked]>
Date: Wed, 16 Nov 2016 11:26:10 -0800

Johan Ihren and I and Olaf had a competing ID that delt with shelf life and
embedded devices w/o an easy way to update key info.  RFC 5011 won out
since shelf life and embedded devices were considered edge cases.

/Wm

On Wednesday, 16 November 2016, Tony Finch <[email-masked]> wrote:

> Wessels, Duane <[email-masked] <javascript:;>> wrote:
> >
> f.anthony.n.finch  <[email-masked] <javascript:;>>  http://dotat.at/  -  I
> xn--zr8h punycode
> [email-masked] <javascript:;>

---

From: Steve Crocker <[email-masked]>
Date: Wed, 16 Nov 2016 11:44:33 -0800

I recall a discussion several years about having a site that would have all of the keys accumulated over time.  A query to it would return the current key.  It's roughly analogous to using a root hints file to find a current root server and from that the full set of current servers.

This wouldn't be hard to do, but it also wasn't considered terribly urgent.

Steve 

Sent from my iPhone

> On Nov 16, 2016, at 11:26 AM, william manning <[email-masked]> wrote:
> 
> Johan Ihren and I and Olaf had a competing ID that delt with shelf life and embedded devices w/o an easy way to update key info.  RFC 5011 won out since shelf life and embedded devices were considered edge cases.
> 
> /Wm 
>

---

From: Tony Finch <[email-masked]>
Date: Wed, 16 Nov 2016 20:04:44 +0000

Steve Crocker <[email-masked]> wrote:
> I recall a discussion several years about having a site that
> would have
> all of the keys accumulated over time.  A query to it would return the
> current key.  It's roughly analogous to using a root hints file
> to find a
> current root server and from that the full set of current servers.

You wouldn't want to depend on a single server, because that just moves
the point of trust to a different key, and fails to eliminate the single
point of failure.

Chaining forward through the history of keys and signatures is pretty
good, but I don't know how a client could prove freshness or (god
forbid) protect itself against compromise of an old key.

The quorum-of-witnesses idea could handle all these problems.

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--
  zr8h punycode

---

From: Evan Hunt <[email-masked]>
Date: Wed, 16 Nov 2016 20:39:11 +0000

> Does that make any sense?

I believe that's what the TALINK RR type is for. The draft seems to
have fizzled back in 2010, but I still think it's a good idea.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Nov 2016 08:46:25 +1100

There is also the physical solution.  Have removable storage for
the key and update the key using this externally when reqired.  Nano
sims or micro sd card would be a good form factor for this.  Pick
a standard file name and you just have them sitting on the shelves
in stores with the key date printed on the packaging.

Is it that hard to add a sim or sd card reader?  This is the solution
the cable industry uses for its crypto issues but with bigger form
factor cards.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: joel jaeggli <[email-masked]>
Date: Thu, 17 Nov 2016 06:57:20 +0900

> I don't think its possible to have a solution that works for devices on the shelf for an arbitrarily long time.  You posed the problem as 10 years, which I think is an unrealistically long time.

A decade is well within the service range of all sorts embedded systems.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2016 07:14:03 +0900

Embedded systems of this sort need to have a management process so that
that can be updated. This is needed for more reasons than DNSSEC. Putting a
ten year old device on a network without upgrading the firmware is
irresponsible.

On Nov 17, 2016 06:57, "joel jaeggli" <[email-masked]> wrote:

> the shelf for an arbitrarily long time.  You posed the problem as 10 years,
> which I think is an unrealistically long time.
>

---

From: Dan York <[email-masked]>
Date: Wed, 16 Nov 2016 22:28:18 +0000

Mark,

I agree that a physical solution could be a workable option (and a nice one), BUT....

On Nov 17, 2016, at 6:46 AM, Mark Andrews <[email-masked]<mailto:[email-masked]>> wrote:

... the home CPE market is extremely LOW-margin right now. Service providers and regular home users are looking for the cheapest options out there. Adding in a card reader adds cost and complexity - and a potential tech support issue - and the reality is that I suspect the *vast* majority of users will not ever run into this issue.  Most users will buy the box and connect it to their network and have the trust anchors just work.

Given the low margin, my suspicion is that most CPE manufacturers would NOT want to add in any additional components to solve what for them would be an edge case in terms of volume.

Just my 2 cents,
Dan

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 17 Nov 2016 00:21:18 +0100 (CET)

----- Original Message -----
> From: "Emily Shepherd" <[email-masked]>
> To: "Mikael Abrahamsson" <[email-masked]>
> Cc: "dnsop" <[email-masked]>
> Sent: Wednesday, 16 November, 2016 14:26:53
> Subject: Re: [DNSOP] DNSSEC operational issues long term

> replace its root certificate?

Not only replace - but the ecosystem changes.  If you wake-up a device
that has been in box for 10 years, it has woke up to a work where
Let's Encrypt is largest CA.  And how likely it has support for modern
crypto, or heck even for SHA2 CA trust anchors.

If your device supports crypto it has to be vendor supported for all
those 10 years, because frankly the world spins so fast now, that there
are so many little things that could break, that DNSSEC is a least of
your problems.

Vendor has to provide a way how upload a new firmware (possibly in a way
a common user can do that).  Our phones are supported for 2-3 years and
that's only when we are lucky.  I strongly believe that you have built
an use case to prove something is wrong, but I think it's your use case
that's wrong in this case.

Cheers,
--
 Ondřej Surý -- Technical Fellow
 --------------------------------------------
 CZ.NIC, z.s.p.o.    --     Laboratoře CZ.NIC
 Milesovska 5, 130 00 Praha 3, Czech Republic
 mailto:[email-masked]    https://nic.cz/
 --------------------------------------------

---

From: Matt Larson <[email-masked]>
Date: Wed, 16 Nov 2016 15:35:11 -0800

> On Nov 16, 2016, at 1:56 AM, Mikael Abrahamsson <[email-masked]> wrote:
> 

Since we haven't done a root KSK roll yet, a general answer to that question isn't possible.  But for the upcoming KSK roll, barring any extremely low-probability events, the DS record parameters for the next KSK will be published in the root-anchors.xml file (https://data.iana.org/root-anchors/root-anchors.xml) in early February, 2017, and the actual rollover event (when the new key begins signing the root zone DNSKEY set and the old key no longer signs) occurs on October 11, 2017.  That's a nine-month window for the worst-case scenario you referred to of a box being manufactured right before the new key.

During those nine months you'll see ICANN folks out and about repeatedly telling anyone who'll listen about the new key.  In parallel, we're also reaching out to developers and integrators to get the new key in their pipeline.  We have fewer contacts with manufacturers of embedded systems, so if you know any hardware manufacturers who care about the root KSK, please contact me privately so we can contact them.

Another way to deal with this issue is for devices to bootstrap the root trust anchor from the aforementioned root-anchors.xml file, which is the canonical listing of current root zone trust anchors.  That file is signed by a cert that chains up to the ICANN CA, which currently expires in December, 2029.  I realize this suggestion only moves the problem to another level: a device needs to trust the ICANN CA, and eventually that key will roll, as well.  But 2029 is a long time away (at the moment).

In my opinion, in a perfect world, any software or device with the root trust anchor configured by the developer/integrator/manufacturer would check the root-anchors file upon startup and then use RFC5011 to stay current.  Or, as an alternative to RFC5011, just periodically re-check the root-anchors.xml file.

Paul Hoffman of ICANN and Jakob Schlyter of Kirei have written a tool called "get_trust_anchor.py" that uses base Python (no additional libraries required) and needs only openssl to retrieve and validate root-anchors.xml; see https://github.com/kirei/dnssec-ta-tools.  For background, see Paul's recent DNS-OARC presentation: https://indico.dns-oarc.net/event/25/session/2/contribution/21/material/slides/0.pdf.

Matt

--
Matt Larson
VP of Research, Office of the CTO, ICANN

---

From: Matthew Pounsett <[email-masked]>
Date: Thu, 17 Nov 2016 08:49:47 +0900

> A decade is well within the service range of all sorts embedded systems.

Service range, sure.  But back-room storage range?  I agree it's an
unreasonably long time to have something to sit on a shelf, never-used, and
then expect it to work when powered on.

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 17 Nov 2016 01:02:10 +0100 (CET)

----- Original Message -----
> From: "Dan York" <[email-masked]>
> To: "Mark Andrews" <[email-masked]>
> Cc: "Evan Hunt" <[email-masked]>, "Bob Harold" <[email-masked]>, "dnsop" <[email-masked]>, "Mikael Abrahamsson"
> <[email-masked]>
> Sent: Wednesday, 16 November, 2016 23:28:18
> On Nov 17, 2016, at 6:46 AM, Mark Andrews < [ mailto:[email-masked] |
> [email-masked] ] > wrote:
> 
> ... the home CPE market is extremely LOW-margin right now. Service providers and
> regular home users are looking for the cheapest options out there. Adding in a
> card reader adds cost and complexity - and a potential tech support issue - and
> the reality is that I suspect the *vast* majority of users will not ever run
> into this issue. Most users will buy the box and connect it to their network
> and have the trust anchors just work.
> 
> Given the low margin, my suspicion is that most CPE manufacturers would NOT want
> to add in any additional components to solve what for them would be an edge
> case in terms of volume.

This is the main problem.  Most CPE manufacturers don't give a damn
about their devices when they are able to sell them successfully
to unsuspecting people.  So I would suspect that if you bought
a low-end device supporting DNSSEC early next year and let it
collect a dust for a single year, there's a high chance it won't
work either, because there would be no way how to update neither
the firmware nor the trust anchors.  And even with the usual 2
year warranty most people would not just bother to return faulty
device to the seller, because $20 is not worth it.  And that's
exactly the reason why those vendors are able to do it.  Most
people just don't care...

And I am not convinced that we should design protocols to cater
the device vendor irresponsible behavior toward their products.

Cheers,

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Nov 2016 11:04:32 +1100

In message <[email-masked]>, Dan York writes:
> On Nov 17, 2016, at 6:46 AM, Mark Andrews
> <[email-masked]<mailto:[email-masked]>> wrote:
>
> ... the home CPE market is extremely LOW-margin right now. Service
> providers and regular home users are looking for the cheapest options out
> there. Adding in a card reader adds cost and complexity - and a potential
> tech support issue - and the reality is that I suspect the *vast*
> majority of users will not ever run into this issue.  Most users will buy
> the box and connect it to their network and have the trust anchors just
> work.

They will have a box that is flakey, get a new box and throw the
old one in the draw.  The new one will die and they will pull out
the old box as a temporary replacement.

That said as long as you can get into the box and disable validation
temporarially you can bootstrap DNSSEC.  Such boxes are almost certianly
going to need their clocks to be set etc.

> Given the low margin, my suspicion is that most CPE manufacturers would
> NOT want to add in any additional components to solve what for them would
> be an edge case in terms of volume.
>
> Just my 2 cents,
> Dan
>
> --
> Dan York

---

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Nov 2016 00:26:39 +0000

On 11/17/16, 08:49, "Matthew Pounsett" wrote:
>On 17 November 2016 at 06:57, "joel jaeggli" wrote:
>
>Service range, sure.  But back-room storage range?

The day before I flew here I took time to unbox a printer my wife bought in November 2015.  She must have bought it from some overstock retailer on a whim, once it arrived it just sat.  Upon opening the box, it looked like the unit might have been manufactured in 2011 or so, meaning, 5 years on the shelf.  I mention this as a data point - in the consumer electronics world, things might be boxed for quite a while in the retail channel.

(And we wonder why protocol enhancements take time to roll out!)

There's been a lot of research consideration of how shelved or otherwise disconnected devices catch up.  I recall 20 years ago this topic was amongst the issues in the labs where I worked, the usual use case involved submarines surfacing.  (Not after 10 years, but after some considerable time.)  There's the TALINK thing (TYPE58) in the registry of resource record types which lists Wouter Wijngaards as a reference (as opposed to a document ;)).

I deal with a lot of dusty stuff.  If there's dust on the unit, you know it's going to need some care and feeding until it's back up to date.  I don't expect to be able to have an automated process in all cases.

As Matt said, for the global public DNS root zone's secure entry points, there are multiple sources for it.  Anyone trying to start vintage equipment will be able to manually run it.  If someone doesn't know how to do this, they'll probably donate the box to GoodWill and take the tax write off.

(I have a 1988 RCA 19" TV with the old-US-style tuner.  I can get images on it but I need to hook up a bunch of signal converts to do that.  But the space it used and the power it draws makes it a better economic choice to put it into a landfill - as the prices for the materials in it decline below the level where recycling is beneficial.)

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 17 Nov 2016 01:44:59 +0100 (CET)

> ten year old device on a network without upgrading the firmware is

We have been discussing zerotouch (ie 0 day no-human-intervention plugin 
of device). This includes the device configuring itself by means of 
different methods, and also software-updating itself before it starts to 
provide any services.

DNSSEC (possibly DANE) has been proposed to be one way of finding this 
configuration. This is now obviously out of the question unless the 
problem I described can be solved.

So this all boils down to:

Do the people involved in DNSSEC want their protocol to be part of the 
long term solution of securing boostrapping things? Yes? No?

Right now the answer is no. 9 months shelf life and then DNSSEC fails is 
just not usable for things that don't have active human intervention in 
its configuration and setup.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 17 Nov 2016 10:00:15 +0900

> the same system see either DNSSEC failures or answers that were not

It is a fundamental problem. For short periods (eg up to 10 years) it is possible to disable dnssec, fetch the icann key bundle that is signed with a long term key you have on the device. Grab and verify the new key and then re-enable dnssec.

Of course that still leaves time as an issue. If you trust the icann bundle, you can get rough time from the rrsig record on the root zone SOA record.

And this all also assumes the icann key bundle hasn't been compromised or blocked or is being replayed from 10 years ago. Doing multiple scattered queries that validate to the root might help give you some assurance (especially from an online signing site like cloudfare using randomized queries)

A more vendor like approach is to disable dnssec and fetch software updates, using the buildin vendor public key. Most concerns from above apply here too.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 17 Nov 2016 10:04:57 +0900

Sent from my iPhone

> On Nov 16, 2016, at 22:41, Bob Harold <[email-masked]> wrote:
> 
>> This is not well thought out, but what jumps to mind is to keep a chain of signatures in the root DNS that links from the original KSK up through the current KSK (or at least the last 10 years).  Perhaps a different record type, so it is only sent if asked for.
> 

The problem is that it does not protect against key compromise, either by operational causes or by mathematical progress.

Paul

---

From: George Michaelson <[email-masked]>
Date: Thu, 17 Nov 2016 10:06:13 +0900

btw this is not in any sense a novel problem. Anyone who owns a Dell,
and uses iDrac will be familiar with the "your certificate chain to
this console java app is expired" problem. It can be fixed, but it
requires effort.

And alongside the crypto age-out problem, the dependency on java is
increasingly a problem: browser-embedded java no longer runs in Chrome
due to deprecation of the NAPI model, so you may well find you cannot
run the signed code blob for reasons un-related to the crypto, after
10 years.

I welcome people designing models to try and deal with age-of-system,
but making this make-or-break for DNSSEC keyroll at the apex is I
think, stepping too far. Given what has been said about out-of-band
repositories of the longer-term keystate, you should be able to
construct trust in the aged key transition to the new key and move on
with your life.

I am more worried that inside 10 years, trust in the private key may
become false. What do you propose doing, if your sealed unit box comes
up with what in the future is morally MD5 password with no salt and
the value 'calvin' ?

-G

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 17 Nov 2016 02:11:15 +0100 (CET)

----- Original Message -----
> From: "Mikael Abrahamsson" <[email-masked]>
> To: "Ted Lemon" <[email-masked]>
> Sent: Thursday, 17 November, 2016 01:44:59

> its configuration and setup.

Again, you are using unfair arguments.  The devices have to cope with
that and it doesn't have to be a protocol design.

Say the vendor used WoSign, StartSSL or other wonky CA that will be
deprecated and now the firmware site uses <random new> CA, that didn't
exist before.  The same question could be rephrased as:

Do the people involved in PKIX want their protocol to be part of the
long term solution of securing bootstrapping things? Yes? No?

Or you can accept the fact that you can use cross-signed secure material
and you might happen to have a public key for that.  For PKIX, that would
be a different CA that cross-signed the new one; for DNSSEC, that would
be the ICANN-CA.  Inventing new knobs and workarounds for dusty devices
in the DNS protocol won't improve this (much).

Cheers,

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 17 Nov 2016 02:45:24 +0100 (CET)

> that and it doesn't have to be a protocol design.

Agreed. It can also be method design. There have been some suggestions in 
this thread for ways to handle the problem. I have not seen any that is 
actually an RFC, preferrably a BCP type document that descibes the problem 
and suggests how it can be handled.

Or is there a document I have missed I can point vendors and IETF people 
to, to understand and handle this DNSSEC property (that doesn't seem to be 
well known, I talked to several people this morning who had no idea this 
DNSSEC limitation existed).

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 17 Nov 2016 03:29:02 +0100 (CET)

Mikael,

the operation of the root zone and signing of the root
zone is in the ICANN/IANA bailiwick.  Therefore most of
the relevant document to the RZ DNSSEC operations can
be found at https://www.iana.org/dnssec/ and the document
you are most interested in is here:
http://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.html
+ the files https://www.iana.org/dnssec/files

It might be worth letting them know if you feel that
the documentation is incomplete or inaccurate.

~~~

As a side note for dnsop: It might be worthwhile to either
revive draft-ietf-dnsop-dnssec-trust-anchor as Informational
or let the IANA adopt that as an IANA document.

Cheers,

----- Original Message -----
> To: "Ondřej Surý" <[email-masked]>
> Sent: Thursday, 17 November, 2016 02:45:24

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 17 Nov 2016 04:00:19 +0100 (CET)

> the documentation is incomplete or inaccurate.

That document lists where I can get stuff. It doesn't list any procedures 
or recommendations how I would get from my non-DNSSEC working state (or 
even suggestions how I understand that I am in that state and it's because 
my key material is too old) , perform some operations, and now I 
understand that I am in a working state.

That's what a BCP could do.

---

From: Shane Kerr <[email-masked]>
Date: Thu, 17 Nov 2016 13:43:21 +0800

Ondřej,

At 2016-11-17 01:02:10 +0100

> the device vendor irresponsible behavior toward their products.

While you're not wrong, I think the characterization is slightly
unfair to CPE vendors.

For most electronics equipment (pre-IoT) once you sold it your job as a
manufacturer was basically done. You don't have to issue security
patches for the keyboard or firmware upgrades to the monitor because
the meaning of the wires in the VGA standard has changed out from under
it.

With anything connected to the Internet it seems the only thing that we
can do is constantly be patching and fighting against the latest
exploits of our protocols and implementations. Unless we are going to
throw away all practical engineering and only use systems that are
provably correct in a mathematics sense(*), that's probably how it is
going to stay.

I infer that you agree that the reason that CPE equipment sucks is
because the business model is wrong. The traditional vendor approach of
selling a thing and then being done with the business is broken. This
is one of the many reasons that IoT equipment sucks and is doing to
continue to suck, until the costs and profits of managing systems
long-term align. But not only *vendors* like this approach, *consumers*
like this approach. (Me too, for the record. I would not be thrilled if
I got a bill for $1 every year to keep my mouse up to date.)

There are several possible models that would be better: subscription,
open systems (so a 3rd party can sell improvements & upgrades), and
so on. Unfortunately nobody seems to care about these issues, since the
vendors are making money by the fistful (a few pennies at a time) and
policy makers take that is a sign that everything is fine.

Cheers,

--
Shane

(*) Noting of course that systems that express things in precise
    mathematics are often incomprehensible to experts, much less
    non-experts in a given subject area. Or rather, "be careful what
    you ask for, you might get it". ;)

---

From: Tony Finch <[email-masked]>
Date: Thu, 17 Nov 2016 13:10:28 +0000

Edward Lewis <[email-masked]> wrote:
>
> There's been a lot of research consideration of how shelved or otherwise
> disconnected devices catch up.  I recall 20 years ago this topic was
> amongst the issues in the labs where I worked, the usual use case
> involved submarines surfacing.

One example which comes up a lot on the LEAPSECS mailing list is radio
transmission sites, where hardware is kept on the shelf as a cold spare
for installation by non-expert remote hands in case the live equipment
lets out its magic smoke.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Viking, North Utsire, South Utsire, Forties, Cromarty, Forth, Tyne: Westerly
or southwesterly, becoming cyclonic, 5 to 7, increasing gale 8 or severe gale
9 for a time in South Utsire and southeast Forties, decreasing 4 at times.
Moderate or rough, but becoming mainly slight in southeast Forties, Cromarty,
Forth and Tyne. Squally showers, thundery at times. Good, occasionally poor.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 17 Nov 2016 15:16:56 +0100

>policy makers take that is a sign that everything is fine.

Looking at this from a European perspective (regulations vary in
different parts of the world), you can expect the manufacturer to build a 
device that will work correctly for some period of time. I think the
European (default) minimum is 2 years.

So if the device develops a fault during that period, it has to be repaired
or replaced by the seller. Needless to say, security issues are manufacturing
defects that are not exempt from this.

If internet connected devices continue to do damage in the next years, it is
not unreasonable to expect that the manufacturers will at some point be forced
to pay for the damages caused by the abuse of those devices.

So part of selling a device that is intended to be connected to the internet is
to make sure that security issues can be patched.

At the same time, if a device stops working because of a DNS root KSK roll over
then it's reasonable to demand that the seller makes it work again.

Of course, a manufacturer can choose whatever clumsy user interface is cheapest.

My preference for general purpose, autonomous devices, is that they check
if firmware updates are available. That way the manufacturer can promptly
fix security updates, but it also allows for changes in key material, etc.
I think this is easy to do. There are some things you can't protect against
(signature keys leaking) but there are plenty of other accidents that happen
already.

I guess anybody can write a BCP for that device class, it doesn't even have
to be the IETF.

A more complex class is a device that should be able to bootstrap even if only
a limited part of the internet is reachable. For example after some kind of
disaster. That may require carefully documenting what protocols are used and in
what way, to reach a stable secure state.

---

From: Jacques Latour <[email-masked]>
Date: Tue, 22 Nov 2016 14:21:23 +0000

Make sure your CPE supports IPv6 only operations before putting on the shelf, it's hopefully IPv4 will be decommissioned 10 years from now, so DNSSEC bootstrap could be moot point.

>-----Original Message-----
>From: DNSOP [mailto:[email-masked]] On Behalf Of Mikael
>Abrahamsson
>Sent: November-16-16 8:45 PM
>To: Ondřej Surý
>Cc: dnsop
>Agreed. It can also be method design. There have been some suggestions in this
>thread for ways to handle the problem. I have not seen any that is actually an
>RFC, preferrably a BCP type document that descibes the problem and suggests
>how it can be handled.
>
>Or is there a document I have missed I can point vendors and IETF people to, to
>understand and handle this DNSSEC property (that doesn't seem to be well
>known, I talked to several people this morning who had no idea this DNSSEC
>limitation existed).
>
>--

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 29 Nov 2016 08:31:48 -0500

> On Nov 16, 2016, at 5:05 AM, George Michaelson <[email-masked]> wrote:
> 

IMHO the device should have two sources of truth for DNSSEC root TA 
a) DNS via RFC5011 
b) Secure Software update from the vendor 

If both fail then operator should be invoked. 

There are other options but they all go into what I call “opportunistic learning” and are not documented
TALINK was one of them, 
PGP signed TA from known address is another one, 
sending lots of queries and learning current root key is another 

In short if a device has only what it is configured with at factory as source for DNSSEC TA the device is has a good chance of being a brick 
when it is connected. 

You are right we should give some guidance to OS and Systems manufactures about how to handle DNSSEC rollovers 

Olafur

---

From: Matt Larson <[email-masked]>
Date: Wed, 30 Nov 2016 10:43:18 -0500

> On Nov 29, 2016, at 8:31 AM, Olafur Gudmundsson <[email-masked]> wrote:
> 

Did you see my message earlier in the thread?  Is there a reason you don't include a third option: retrieving the trust anchor file published by IANA/PTI (https://data.iana.org/root-anchors/root-anchors.xml) and validating with the detached S/MIME signature published in the same place (https://data.iana.org/root-anchors/root-anchors.p7s)?  That signature chains to the ICANN CA cert, which currently expires in 2029.  Sure, it's more code, but it can all be done with OpenSSL, for example.

Matt

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 30 Nov 2016 17:00:19 +0100 (CET)

On Wed, 30 Nov 2016, Matt Larson wrote:

> Did you see my message earlier in the thread?  Is there a reason you 
> don't include a third option: retrieving the trust anchor file published 
> by IANA/PTI (https://data.iana.org/root-anchors/root-anchors.xml) and 
> validating with the detached S/MIME signature published in the same 
> place (https://data.iana.org/root-anchors/root-anchors.p7s)?  That 
> signature chains to the ICANN CA cert, which currently expires in 2029. 
> Sure, it's more code, but it can all be done with OpenSSL, for example.

This sunds like a workable solution.

It would be great if ICANN could write a document outlining how to do 
this and perhaps even provide FOSS example code.

---

From: Tony Finch <[email-masked]>
Date: Wed, 30 Nov 2016 16:00:03 +0000

Matt Larson <[email-masked]> wrote:
>
> Is there a reason you don't include a third option: retrieving the trust
> anchor file published by IANA/PTI
> (https://data.iana.org/root-anchors/root-anchors.xml) and validating
> with the detached S/MIME signature published in the same place
> (https://data.iana.org/root-anchors/root-anchors.p7s)?  That signature
> chains to the ICANN CA cert, which currently expires in 2029.

Is there anything like the KSK operator DPS for that CA cert and the
signatures that are generated with it?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Southwest Viking: Westerly veering northwesterly 6 to gale 8. Rough or very
rough. Rain at times. Moderate or good.

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 30 Nov 2016 08:09:45 -0800

On 30 Nov 2016, at 8:00, Mikael Abrahamsson wrote:

>> don't include a third option: retrieving the trust anchor file 
>> published by IANA/PTI 
>> (https://data.iana.org/root-anchors/root-anchors.p7s)?  That 
>> signature chains to the ICANN CA cert, which currently expires in 
>> 2029. Sure, it's more code, but it can all be done with OpenSSL, for 
>> example.
>

Such a document is in process. A FOSS tool can be found at 
https://github.com/kirei/dnssec-ta-tools/tree/master/get_trust_anchor 
(issues and pull requests invited!), but it might move in the future to 
an ICANN or PTI location. A few months ago, Jakob and I did a 
presentation about it at OARC.

--Paul Hoffman

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 30 Nov 2016 11:18:58 -0500

On Wed, Nov 30, 2016 at 10:43 AM, Matt Larson <[email-masked]> wrote:

> Did you see my message earlier in the thread?  Is there a reason you don't
> include a third option: retrieving the trust anchor file published by
> IANA/PTI (https://data.iana.org/root-anchors/root-anchors.xml) and
> validating with the detached S/MIME signature published in the same place (
> https://data.iana.org/root-anchors/root-anchors.p7s)?  That signature
> chains to the ICANN CA cert, which currently expires in 2029.  Sure, it's
> more code, but it can all be done with OpenSSL, for example.
>
> Matt
>
>
I saw your message, the issue is  it is not at this point well documented
how a Vendor can integrate this into
their setup scripts.
What is needed is Documentation as how to fetch this, and preferably a Open
Source tool demonstrating the process and verification.
The fundamental question is "what validates the root-anchors.xml file and
how can I trust that in 10 years?"

Olafur

---

From: "John Levine" <[email-masked]>
Date: 30 Nov 2016 22:49:49 -0000

>this and perhaps even provide FOSS example code.

$ wget https://data.iana.org/root-anchors/root-anchors.xml
$ wget https://data.iana.org/root-anchors/root-anchors.p7s
$ openssl smime -verify -in root-anchors.p7s -inform der -content root-anchors.xml -noverify

If you have the ICANN CA cert lying around, replace -noverify with -CAfile <cacertfile>

R's,
John

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 30 Nov 2016 16:53:23 -0800

On 30 Nov 2016, at 14:49, John Levine wrote:

>>> published
>>> 2029.

As stated earlier today, there is such a tool at 
<https://github.com/kirei/dnssec-ta-tools/tree/master/get_trust_anchor>. 
It has a few more steps than what you listed here, namely ones to 
actually validate that the KSK in the root zone matches the one in the 
root-anchors.xml file, and that the contents of the file are sane.

--Paul Hoffman