[dconn] Re: Secdir review of draft-kowalik-domainconnect-02

[[e-mail]]

Hi Charlie,

Thank you for your early review,

Commented below with [PK].

On 22.12.25 07:50, Charlie Kaufman wrote:
> Reviewer: Charlie Kaufman
> Review result: Has Issues
>
> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.
>
> This document specifies a protocol by which operators who to update DNS entries maintained by a third party DNS provider can request such changes in a standardized way. While the document doesn't say, I infer that today third party DNS providers all have their own mechanisms for accepting such requests and large operators who must work with many third parties have to learn how to deal with each one. If so, a protocol of this sort seems woefully overdue and would be welcomed by the community. DNS providers would face pressure to support the protocol.
>
> I'm concerned that this standards track RFC is coming in as an individual contribution. I would expect there to be widespread interest and that the authors would find or start an appropriate working group.
[PK] This is now an adopted WG document (DCONN WG).
>
> This is not my area, so many of my comments may be ill-informed, but I will offer them anyway for whatever they are worth.
>
> Section 3.2: Use Cases out of scope says:
>
>     While Domain Connect offers significant advantages in automating DNS
>     configuration, it's important to recognize scenarios where it might
>     not be the ideal solution:
>
>     *  *Automation or CI/CD Pipelines:* Domain Connect is primarily
>        designed for user-driven DNS configuration, where an end user
>        grants consent and applies changes.  Automating this process
>        within CI/CD pipelines or other automated workflows can be
>        challenging, as it requires obtaining and securely storing OAuth
>        tokens beforehand.  However, if authorisation tokens are pre-
>        obtained from a user-driven setup process, Domain Connect can be
>        also integrated into automation workflows.
>
> I would think that an automated deployment pipeline would be the common case and that the protocol should be designed for that case, where manual "user-driven" configuration is a necessary but hopefully uncommon case. This has immediate security implications, in that it would be appropriate to support some authentication protocol like using PKIX certificates for TLS authentication of people or processes rather than using OAuth (which is aimed at authenticating human users). I couldn't tell how difficult it would be to be agile with respect to security mechanisms or how difficult it would be to work with OAuth.
[PK] Complexity of such considerations was so far the main issue to put 
it out of scope or park at least. Automated DNS configuration by a 
technical system is usually addressing a different problem definition 
(a.k.a. standardised DNS configuration API), where likely the securities 
and trust model of domain connect are oversized or even not necessary at 
all. Anyway I would be happy to see discussion on this on the mailing 
list in case anyone considers this problem worth solving.
> I'm suspicious of the synchronous flow. Is it common for DNS providers to be able to make updates in real time? I would expect - especially in cases where DNSsec is supported - that it might be better to be able to accept a request (so the sender is guaranteed it will happen eventually, possibly with an estimate or commitment as to how long it will take) rather than delaying a response until the update is completed, especially given that if there is a crash while waiting the requestor doesn't know whether he has to resubmit it.
[PK] The synchronous flow does not mean the changes are deployed and 
propagated. "the sender is guaranteed it will happen eventually" is what 
actually shall happen. I will take into the text if it may be put more 
explicit.
>
> Section 5.2.1 is very confusing. It is trying to express what trust various components are placing on others (I think). But it comes off as either being obvious or expressing something so subtle that it goes over my head.
[PK] There was an explicit request from the previous discussion to add 
trust model. Maybe now it's too verbose. I will take a look.
>
> I really like the idea (in Section 7) of posting configuration information in DNS, though it is sufficiently rare that I wonder whether the DNS folk will object.

[PK] DNS is only holding a pointer to a configuration end-point (link 
domain->provider) via simple TXT record on _domainconnect label, the 
configuration itself is an HTTP endpoint.

> And posting information about how the information should be displayed on the user's screen seems over the top.
[PK] Yes, this feedback comes a lot and will be even more reduced in the 
next version.
>
> Nits:
>
> Section 3.2 vs. Section 8.2.1.2: authorization or authorisation -- pick a spelling and stick with it.
>
> Section 4: "mean of communication" -> "means of communication"
>
> Section 7: "suceeds" -> "succeeds"
>
> Section 8.4.1: "asyncronous" -> "asynchronous"
>
> Section 8.4.3: "primarly" -> "primarily"
>
> Section 8.4.3: "temporarilly_unavailable" -> "temporarily_unavailable"
>
> Section 10.3: "specifed" -> "specified"
>
> Section 10.4: "desireable" -> "desirable"

[PK] Noted, thanks.

Kind Regards,
Pawel