Matt - do you have an update of the document or to your comments below?
Working group - are there any other comments or review of this document.
We need additional review before we can go to working group last call.
Thanks!
Jim
On 14 Sep 2017, at 13:36, Matthew Pounsett wrote:
On 16 June 2017 at 10:03, Antoin Verschuren <i...@antoin.nl> wrote:
Dear authors,
I could finally find some time to make a more thorough personal
(chair-hat
off) preliminary review on this document.
Here are my comments:
Hi Antoin. My apologies for taking so long to getting around to
replying.
:)
I think we've addressed most of your notes either in Jacques's reply
or in
the latest update, but I wanted to discuss a couple of things
independently.
" This document describes a simple protocol that allows a third party
DNS operator to update DS records for a delegation, in a trusted
manner, without involving the Registrant for each operation. This
same protocol can be used by Registrants.”
This sounds dubious. Is the registrant involved or not?
I would say:
" This document describes a simple protocol that allows any
DNS-operator to update DS records for a delegation, in a trusted
manner, without involving any intermediate administratieve
entities
between the DNS-operator and the parent.”
I agree that the wording in the current draft is a bit awkward.
However,
your suggestion isn't quite correct either, since we're expecting this
draft to be implemented by registrars in a gTLD environment, and they
are
not the parent.
The intent of the current wording is to point out that this was
developed
to allow third-party operators to update their customers' DNS without
having to involve the customer, but then to also note that advanced
registrants who want to automate their own DS updates can also use it
(it's
not limited to third-party operators).
What the API and processes described in the draft really allow is for
the
registrant or their DNS operator to avoid the *authenticated* web UI
of
their "Registration Entity", whether that be the registrar or the
registry,
because nobody implements a way for a regsitrant to add credentials
for
their DNS operator and we have no reason to expect anyone ever will.
Even
if they did, there's still a scaling problem for the operator.
I'm going to think about a better way to word this paragraph which
doesn't
encourage the reader to think we're setting up something that is
entirely
unauthenticated or unvalidated. If you have any other suggestions
I'm
glad to hear them.
1. Introduction:
"After a domain has been registered, one of three parties will
maintain the DNS zone loaded on the "primary" DNS servers: the
Registrant, the Registrar, or a third party DNS operator.”
I object to this phrasing, as it suggest an entity performs it’s
role as
DNS-operator as part of another role he might play. It’s always the
DNS-operator and only the DNS-operator that maintains the DNS zone.
An entity can act as both registrant AND DNS-operator, registrar AND
DNS-operator, or as a standalone DNS-operator, but an entity never
maintains a zone in any other role than as DNS-operator. They should
be
clearly separated to keep roles and entities clearly defined.
This whole section need a thorough review on definitions of roles and
entities performing multiple roles.
Does this work better?
After a domain has been registered, the DNS operator for the child
zone on
the "primary" DNS servers might be the registrant, the registrar, or a
third party.
3.2 Establishing a Chain of Trust:
This is the section where I have most problems with.
The bootstrapping of a secure delegation can never be done over an
insecure channel such as DNS without a chain of trust for polling the
initial key.
Unfortunately, I have not followed the discussions for RFC8078, but
when I
read that now, I think paragraph 3.3 and 3.5 from RFC8078 are a
terrible
mistake security wise, and a downgrade from previous practice. I
believe
that insertion of the first key at the parent should always have been
over
a secure channel, or confirmed over a secure channel, and in the
absence of
a chain of trust in DNS prior to a secure delegation, the only way to
do
that is over the secure administrative channel such as EPP or another
proven secure channel which DNS without DNSSEC validation is not.
I challenge RFC8078 that it probably had too little review from
security
folks, and I don’t want to make the same mistake here, which makes
it even
less secure by saying "Once the Registrar sees these records it
SHOULD
start acceptance processing.”
No way. It should never accept a security proof or security inception
process over an insecure channel.
Also, the introduction of this document only states "Update DS
records”
which I agree with, but Establishing a Chain of Trust is not updating
but
bootstrapping.
I think we're going to have to continue to disagree, here. Not only
has
8078 been published, but there are already registries implementing
security
bootstrapping via CDS. We've updated the text to be more explicit
about
this, and I intend to strengthen the security considerations statement
more
that this is a risk that a registration entity needs to carefully
consider
before implementation.
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
