North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: wrt joao damas' DLV talk on wednesday

  • From: Paul Vixie
  • Date: Tue Jun 13 17:49:54 2006

> > > ... we're trying to sign up some registrars, starting with alice's,
> > > who can send us blocks of keys based on their pre-existing trust
> > > relationships.
> > 
> > so a key roll or change of delegation requires two levels of human
> > intervention to work?


in the normal, non-DLV DNSSEC-bis model, a registrant informs its registrar of
new KSK's before existing KSK's expire (or perhaps during revocation events)
using the same authenticated automation they would use to change NS RRs or
arrange for payment of fees or whatever.  the registrar (like alice's for ISC)
then tells the appropriate registry (like Afilias-PIR-UltraDNS, for .ORG) the
new DS RR data using the same (EPP? RRP? fax? carrier pigeon?) authenticated
automated model they would use when changing NS RR data.  no human
intervention at all.

in the DLVified DNSSEC-bis model, the DNS registry (like VeriSign for .COM)
is not yet accepting DS RR data via their EPP interface to their registrars,
although i note with admiration that VeriSign has led the effort to add new
EPP protocol elements to support this new data.  as far as i know, no existing
DNS registry will accept DS RR data.

therefore registrars (like alice's... remember alice? this is a song about
alice) have no place to go with registrant KSK data at this time.  this in
turn keeps most registrars from bothering to collect or store this "useless"
data.  ISC proposes to accept this KSK data (in the form of DLV RRs) via
authenticated automated processes whereby "lots of keys" can be sent to us
by interested/participating registrars.  we do not have a good way of knowing
whether somebody is or isn't the registrant for, but we
think that bank of america's registrar does have a way of authenticating the
registrant.  and we know how to authenticate's registrar.
so there IS a more scalable, untouched-by-human-hands, trust path available.

until we get that working, we're left with the least desireable alternative,
which is accepting keys directly from registrants, and authenticating these
folks the hard way, with human hands and eyeballs.

alas, i repeat myself.  i've said this already.  and if folks aren't going to
read the explainations i really need to discipline myself into not repeating

> DNS-SEC will live and die on the business model. How user-friendly it is
> vs. how necessary it is against what alternatives there are.
> To be honest, waiting for so many years for DNS-SEC, if these questions
> were not answered by now...

to be equally honest, i'm now weary of hearing what can't be done or shouldn't
be done.  anyone who wants to not do dnssec is free to do that, they don't
need to shout it from the rooftop.  anyone else who wants to wait until the
root is signed and NSEC3 is done and automated trust key rollover is done is
welcome to wait -- no shouting is required from any rooftop by those, either.