----- Original Message -----
> From: "Mikael Abrahamsson" <swm...@swm.pp.se>
> To: "Ted Lemon" <mel...@fugue.com>
> Cc: "dnsop" <dnsop@ietf.org>
> Sent: Thursday, 17 November, 2016 01:44:59
> Subject: Re: [DNSOP] DNSSEC operational issues long term

> On Thu, 17 Nov 2016, Ted Lemon wrote:
> 
>> 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.
> 
> 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.

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,
--
 Ondřej Surý -- Technical Fellow
 --------------------------------------------
 CZ.NIC, z.s.p.o.    --     Laboratoře CZ.NIC
 Milesovska 5, 130 00 Praha 3, Czech Republic
 mailto:ondrej.s...@nic.cz    https://nic.cz/
 --------------------------------------------

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to