On Sun, Apr 1, 2018 at 1:59 PM, Paul Vixie <p...@redbarn.org> wrote:
>
>
> Tony Finch wrote:
>
>> Paul Vixie<p...@redbarn.org> 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 ssh/pgp/x509/etc, then the solution for being on the
>>> shelf for several months is, do a software update before you try to go
>>> online.
>>>
>>
>> I think that's a good suggestion for the short term. For the longer
>> term I would like it to be possible to say that DANE is a reasonable
>> way to authenticate software updates, but at the moment it is not.
>>
>
> i believe that software packaging systems will never put that many moving
> parts between their users and their updates. it'll remain some flavour of
> non-distributed keying, like pgp and ssh, simply because of the
> risk/benefit ratio of adding third parties.
>
> i see a bright future for DANE, because of user-driven web and e-mail
> transactions, that are not point-source trust models.
>
>
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698
<https://tools.ietf.org/html/rfc6698>, August 2012.
The RFC was published six years ago. Has anything happened since that
suggests this is the basis for a ubiquitous infrastructure? I am not aware
of anything.
I see a big future for using DNSSEC to distribute authenticated security
policies. But not via the TLSA record. It was tried, it failed.
Prefixed TXT records work and they do not demand end entities consider
their DNSSEC trust root to be trustworthy. Which is kind of essential if
you find yourself in the part of the world where the government is going to
insist that you trust their national DNSSEC root and not the ICANN one.
The only root of trust that is ever going to be acceptable to me is me. And
I am not the only person who thinks that way, the US federal government
developed the BridgeCA concept because US government agencies can't agree
who is going to be the ultimate source of trust among them. So you can be
absolutely certain they are never going to agree to it being ICANN.
On Fri, Mar 30, 2018 at 12:06 PM, Tony Finch <d...@dotat.at> wrote:
> Phillip Hallam-Baker <ph...@hallambaker.com> wrote:
>
> > But even if we accept the need for updates, where does the ground truth
> > for the updates come from?
>
> Your vendor gets to decide :-)
>
>
Well that is precisely the point. One of the chief reasons I uninstall
software on machines is that it keeps making demands for updates.
What people tell each other is good security practice is often wrong or
even broken. We told people to change their passwords frequently for
decades until people did actual research and found that it was a terrible
idea and makes things worse, not better.
Keeping software up to date is one security CONCERN. It is one control that
addresses one potential source of risk in a system. It does not trump every
other concern.
In particular, I have managed systems in the past that have been either
subject to nation state level attack or are obvious targets for such
attack. The idea that such an actor would suborn a
manufacturer is far from far-fetched, it has happened.
Hence my requirement that every actor be their own ultimate source of trust
but with the option to delegate management of that source of trust to a
third party of their choice.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
