Re: [regext] Review of draft-ietf-regext-dnsoperator-to-rrr-protocol-04

[Patrick Mevzek <[e-mail]>]

Hello Matthew,

(I removed the point with which I agree with you or for which I do not have anything else useful to add or no answers to your questions or waiting from other viewpoints to discuss further eventually).

On Tue, Apr 24, 2018, at 20:57, Matthew Pounsett wrote:
> > * Abstract
> >
> > I think it would be best to at least have a sentence explaining the goal
> > before beginning to describe the current situation and its shortcomings.
> > So that people reading it know where you are going to right at the
> > beginning.
> >
> 
> I think I see a way to rearrange the abstract for this.  Does this seem
> better to you?
> 
> This document describes a simple protocol that allows a third party DNS
> operator to: establish the initial chain of trust (bootstrap DNSSEC) for a
> delegation; update DS records for a delegation; and, remove DS records from
> a secure delegation. The DNS operator may do these things in a trusted
> manner, without involving the Registrant for each operation. This same
> protocol can be used by Registrants to maintain their own domains if they
> wish.

I think indeed that it would be better to start with something like that.

> > So is the REST setup really providing you any benefit here?
> 
> It's an existing framework we can use which implementers know how to work
> with.  The alternative is to specify something entirely from scratch.

REST mandates that you identify your resources (like with an ID) and that you act on them through HTTP verbs. I am really not convinced your use case is adapted to this.

> > * 3.1 Identifying The Registration Entity
> >
> > About the automated discovery of the base URL of the API, did you think
> > about using SRV records at the parent? And/or URI or NAPTR?
> >
> > Would also well-known URIs (RFC5785) have something to offer here?
> >
> 
> Initially we dismissed the general idea of inserting RRs into a TLD for
> service discovery because of the issues surrounding gTLDs and the
> ICANN-imposed limitations on what records they can put in their zones.

The limitations are on the apex. You still could publish a record called _dnssec_signaling.$ZONE  SRV .... 
(the label name is bad on purpose)

Also, we all really need to remember that the world is not constrained to gTLDs. I believe that we should build the best protocols we can and then see how to change the policy if needed. Not the opposite way.

> However, I'm starting to think that we should reopen that discussion
> because I'm not convinced that our proposed RDAP extension will ever seen
> the light of day, even assuming that RDAP gets widely adopted in the next
> five years.

Now, with GDPR dramas, it may boost RDAP ;-)

> To that end.... I had a look at 5785 but didn't think it applied.  It's
> more about where to find policy and other meta-data than a
> service-discovery system.

I think it allows not to hardcode paths. See how it is used in the ACME protocol and the RFC6570 URI template document
(not saying all of these solve immediately all your problems, just providing some input on the table)

>  SRV seems to be considered by many in the DNS
> community to have been a mistake, as it tries to overload the namespace
> with meaning that should be in the type. 

I am not in that camp and I see on the contrary that we also try to counter the idea of new RR by just creating records with a leading underscore, so that we swap an RR type for a label.

I think for example the world would be much better if browsers were not hardcoded with 80 and 443 and would just use what SRV records tell them. For one, this would have made middleboxes ossification on these ports far less widespread.

> Lack if implementation aside, URI
> and NAPTR, applied to this use case, would suffer from the same problem as
> SRV:  what meaning specific to this protocol could you infer from the query
> `example/IN/URI`?  We'd have to overload the namespace to use them.

See above, not necessarily example as QNAME but something specific like _dnssec_signalling.example IN URI.

> I'm left thinking we should register our own service discovery RR, after we
> fix the naming problem so that we could come up with a reasonable RR type
> name.  If we define the RR "FOO" for discovery of the entry point of this
> service, then 'example/IN/FOO' is all you need to query for, and it
> requires no additional explanation or processing.

See previous point, I do not think you need a new RR just for that.

[bootstraping DNSSEC by automated scanning of CDS record by registry]
> > If you really want to discuss that practice I believe you would need more
> > data
> > or recommendations like on timings (minimum/maximum periods, hardcoded at
> > registry
> > or depending on zone TTL, etc.)
> >
> 
> Yeah, doing that scanning obviates the need for this protocol.  I think we
> should move that recommendation up to the Introduction and use it as an
> example of when you *shouldn't* implement this.

I would welcome that change.

> > Also, multiple registries do DNS checks after each change and go forward
> > only
> > if everything returns OK (from their very specific local list of tests).
> > There may be a merit to discuss what happens when the child does some
> > CDS/CDNSKEY
> > changes that get automatically picked up by registry (for the one doing it
> > like you advise) but then the DNS checks fails for whatever reason (example
> > among many other possible cases: the child publishes a new CDS without
> > publishing
> > the corresponding DNSKEY in its zone), so no changes happen.
> > How the third party/registrant get notified of that (besides not seeing its
> > wanted change appearing on the registry level)?
> >
> 
> What happens if they do that today?

About DNS checks? The changes is not applied if the tests do not pass and for some other registries the domain could even be suspended I think.

As for CDS scanning I am not aware of many (any) registries doint it today?
Who does?

> > * 3.3 same problem, you are adding something (the registry having to
> > regularly
> > scan the child zone for CDS records) that is not really part of this
> > protocol
> 
> I agree.  I think that should be a MAY, not a SHOULD.  Would that fix your
> concern?

While better, as leaving each implementation to decide, I still think it is not relevant to your protocol and should not exist in a document describing your document. As discussed in DNSOP I think, you should replace all of this by a reference to another document that deals exclusively with technical checks done by registries.

> > * 3.4
> >
> > I was thinking about the signatures lifetime of the records, maybe that
> > should
> > be checked by the parent, so that they do not expire "too soon" ?
> >
> 
> What is "too soon"? 

Good question. What is a good TTL? No idea, but that should be discussed (even if the conclusion is: no good definitive advice) in a separate document.

> If an operator is signing on the fly, then the
> signature lifetime doesn't need to be any longer than the TTL of the
> RRset. 

Agreed.

> And again, this sounds like advice with general applicability to
> all DNSSEC operations, and not just this protocol. 

I agree this is why any point related to technical verifications related to DNSSEC and more generally DNS should not be in this document but referenced from it if you would like.

> > I find the test to be a little harsh: if I read it correctly if even one
> > query
> > timeouts among all of them done each 2 hours during a week (so 84*2 per
> > nameserver
> > to check both TCP/UDP) everything is reset back to its beginning. But
> > network
> > outages can happen and not necessarily under control of the DNS provider,
> > and also
> > the DNS service is available globally through the constellation of
> > nameservers,
> > not necessarily for one of them all the time.
> >
> 
> The text is about the consistency of the response, not the quality of the
> service, so I don't personally see the same implied restriction with regard
> to timeouts.  Do you have a suggestion about how we could make that
> clearer?  The intent here to to prevent an attacker from spoofing responses
> from one or more servers in order to fool the parent into adopting the
> wrong DS.  Since this option bootstraps trust from nothing we intend for
> the tests to be extremely rigorous.

It would probably be difficult for an attacker to spoof responses from more than one nameserver and consistently during a week.
The registry could provide a dashboard to track where the request is at and what responses were gathered.

If you agree that a *missing* response (network timeout, etc.) is just ignored and does not reset the process back at its beginning then I think it would be better.

> > * 4.1 "or VPN"
> >
> > I am against these two words. I see no need for them and in the contrary
> > their presence
> > gives false promises by putting two things on the same level where they
> > are not: even if using a VPN, the access would still need to use TLS. So it
> > is clearly not an "or".
> > Also there is some logical problems in your suite of explanations: you say
> > the protocol
> > does not need any unique authentication, and that TLS would be enough for
> > that.
> > Then you say people can use TLS _or_ VPN: so if using VPN what about the
> > needed features
> > of authentication? You do not say.
> >
> > In short, remove "or VPN" and all problems are solved.
> >
> 
> The requirement is about authentication, not encryption. 

Exactly, which is why, even with a VPN you would still need TLS for end to end authentication. So it can not be "VPN or TLS". The VPN may secure a part of the path but not all of it, while TLS can be end to end for both confidentiality and authentication needs.

Except of course if your use of VPN would be to say that the registry provides a VPN endpoint for registrars to connect to it...

> > * 4.2.1.1.1
> >  I believe a PUT would be more REST-like in this case
> > (kind of "creating" DS data at the registry for the object being the
> > domain)
> > than a generic POST (see my discussion previously)
> >
> 
> POST was chosen there to differentiate it from the PUT request at 4.2.1.3.

I think that HTTP verbs should not be chosen on the basis of "differentiation" between one part and another of the protocol. They should be chosen on the sole merit of what action they encode. If you create a resource, it should be a PUT. POST is more an all-purpose default if nothing more specific matches
(and to be nice with poor client implementations that know only about GET and POST but I am never happy to standardize on the lowest common denominator).

> If I recall correctly, I think we chose to do it that way because we felt
> POST made more sense for new data, while the PUT made sense as a
> modification to existing data. 

While we are entering REST-bikeshedding area, for me it is more PUT to create data and PATCH to update it, or POST as a last-resource.

But again, and more to the point, I do not think your protocol needs the REST framework.

> > * 4.2.1.2
> > Is there a specific reason to separate the case of removing all DS records
> > from the case of generic DS records update detailed after?
> >
> 
> Yes.  Removal of all DS records is a security downgrade, while removal of
> some DS records in the course of updating the DS set is not.  The two
> operations have distinct signals in CDS as well.

Ok I say, but then removal of "some" records could be all records in fact, so end operation is the same. 

> > * 4.3.  Customized Error Messages
> >
> > This is clearly underspecified. How it is formatted in the body of the
> > response?
> > Especially since you later say that it is a protocol for machine to machine
> > communications, so these communications must be framed inside
> > specific structures.
> >
> 
> I believe that since that is the only thing that may be in the body, it was
> assumed it would be a simple text string.  No extended error message is
> ever going to be used directly by a machine.. it would have to be stored
> and made available to a human looking into the results of a request.. so I
> don't think further structure is necessary.  However, we should have
> specified this more clearly.  I don't think it's a bad idea to give it some
> sort of structure, especially to allow for the separation of an extended
> error code and extended error text.
> 
> If we did add structure to the body, my personal preference is for
> something light-weight and human debuggable like YAML or JSON.  Does anyone
> have strong feelings about that, or other formats we should consider?

If you want to be really REST-conformant in spirit, the response format (text, XML, JSON, YAML, etc.) should be under control of the client, with the Accept headers.

Probably one additional reason why I am saying that, for your simple needs of a signalling protocol, the REST-framework is too much, if followed.

> If we really wanted to be simple about it,
> the entire thing could be a single GET URI, or even a custom ICMP message,
> but we felt that as long as we're specifying this we might as well enable
> it to carry more detail than that.

I think this kind of explain many problems: it is not enough of a simple signaling protocol, but too much of something more complicated with authentication built in. I would think this is the core point to address: if DNSSEC related authentication is enough, then make it really just a signaling protocol.

> Even though further authentication of this protocol isn't *technically*
> required, we realize that there may be business requirements that would
> lead a Registrar or Registry to want to limit who can access the servers
> where they provide this service, especially if they've chosen to enable the
> bootstrapping of trust, and there are several places in the document where
> we have a nod to these business requirements.  We feel that mentioning that
> operators may want to implement such limitations is sufficient, and it's
> not our place to specify what they SHOULD be, since it's not technically
> required by the protocol.

I would say have a look at the RFC about EPP over TLS, it has sections about what kind of limitations should be put in place.

-- 
  Patrick Mevzek