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

On Sun, Apr 1, 2018 at 1:59 PM, Paul Vixie wrote: > > > Tony Finch wrote: > >> Paul Vixie wrote: >> >>> i suggest that bind, unbound, powerdns, and so on change their packaging >>> to >>> put the trust anchor in a different upgradeable package (.deb, .rpm,

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

Tony Finch wrote: Paul Vixie wrote: i suggest that bind, unbound, powerdns, and so on change their packaging to put the trust anchor in a different upgradeable package (.deb, .rpm, etc) than the software itself. until and unless the package manager is secured by DANE rather

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

Paul Vixie wrote: > > i suggest that bind, unbound, powerdns, and so on change their packaging to > put the trust anchor in a different upgradeable package (.deb, .rpm, etc) > than the software itself. until and unless the package manager is secured by > DANE rather than by

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

Tony Finch wrote: Paul Vixie wrote: devices which cannot be updated by their makers must expire Definitely. I think the problem that most concerns me is the device that spends 3 or 6 months in a box between manufacturing and deployment, and which expects to do a software

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

Paul Vixie wrote: > > devices which cannot be updated by their makers must expire Definitely. I think the problem that most concerns me is the device that spends 3 or 6 months in a box between manufacturing and deployment, and which expects to do a software update when it is

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

Phillip Hallam-Baker wrote: > So don't you dare claim that software updates are essential, that is an > ideological position learned from a limited set of experience. My position is that software updates extend the lifetime of a device. If a device depends on external

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

It is a hard problem and it is possible that there is actually no solution. All these systems consist of a chain or a graph of signed assertions. There is no intrinsic ground truth in PKI. All that you can do is to define a particular key or set of keys as producing the ground truth for your

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

Michael StJohns wrote: > > There are three questions I have about your solution - > 1) Do you expect it to be usable each time a device boots? Yes. (It's only necessary to consult the witnesses if the device's stored trust anchor doesn't work, for whatever reason. This

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

Apologies for the top post. Thanks for the commentary.  My guess is that we're starting from different assumptions. There are three questions I have about your solution - 1) Do you expect it to be usable each time a device boots?  2) If (1), how long in years to you expect it to be usable? 

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

Michael StJohns wrote: > Interesting thoughts, thanks. I have a slightly different starting point, which doesn't disagree with your argument, but leads to somewhat different consequences. > Proposition 1 (P1):  The initial selection of a root of trust (ROT) on behalf >

[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