On 8/19/21 7:57 PM, Brian Dickson wrote:


On Thu, Aug 19, 2021 at 10:40 AM Peter Thomassen <pe...@desec.io 
<mailto:pe...@desec.io>> wrote:

    Hi Brian,

    The proposal aims to authenticate parental NS and glue records by having 
the parent sign their hash digests, embedded in new types of DS records.

    1.) The separation of the data which requires authentication (parental NS + 
glue records) from the place where authentication is provided can lead to a 
race condition: What happens if updates do the NS or glue records have been 
seen and cached by a resolver, but an old DS RRset is cached (or vice versa), 
so that digests mismatch? How does this interfere with the notion that it is 
acceptable to cache an RRset until its TTL expires?


The process for changing glue or NS records is something that typically is 
already dealt with by domain owners, by a sequence of changes and waiting 
periods based on TTL.
(That generally involves changes to apex NS and delegation NS sets in a 
specific order and involving waiting intervals based on TTL, as well as having 
both sets of NS serving data during the change of NS.)

This would not be that different.
The general practice would be "make before break".
Add DS records to the set, wait, make the changes, wait, remove old DS records 
that are no longer required.
This prevents the mismatches from happening, and is compatible with cache 
assumptions regarding TTL.

Right, that is obviously the right way to avoid the race condition. I had not 
thought of the fact that one can provision multiple DS glue records for the 
same algorithm (but yes, it's just as with any other algorithm), and I think it 
should be mentioned in the draft.


Some follow-up thoughts:

a) If the parent is charged with computing and maintaining DS glue (i.e. the 
registrant does nothing new), then the parent will have to take care that the 
double-provisioning and clean-up is happening, while adhering to various 
waiting times. This requires keeping state on the parental side that previously 
did not have to be kept. Has this been considered?

b) If the parent is *not* charged with computing and maintaining DS glue, then 
the registrant has to do it. Registrants often are already overburdened with 
uploading regular DS records, not to mention following a specifically timed DS 
update producure when all they want is add an A glue record. While this is not 
a problem for ADoT, I think it can be expected that the vast majority of 
registrations, even if the delegation and child zone use DNSSEC, will not get 
secured with DS glue, and not receive any of the benefits of glue 
authentication.

As a consequence, one either has to (a) get the parent involved significantly, 
or (b) the privacy goal of preventing the qname leaking to bogus authoritative 
nameserver will not be met, and the mechanism is effectively reduced to an ADoT 
enabler (no offense intended, using pointed language only to dig deeper and 
spark good discussion).

Do you share this asseessment?

(I am not making a statement on the significance of the qname leak privacy 
issue, but my understanding is that preventing that leak is one of the goals of 
the protocol -- I may be mistaken.)

    3.) Have any experiments been done to determine whether adding RRSIGs to 
parental NS and glue records breaks existing deployments? (Pointers welcome.)


I don't have pointers offhand, but yes, this has been experimented with, is my 
understanding.
(Anyone have pointers? It might be nice to have them handy.)
The results and behavior may have varied, but were definitely not universal 
success.
I'm not sure if some implementation combinations might have "worked", but 
certainly not the majority of combinations.

I really would like to learn of some instances where things went wrong (and 
then look into what went wrong). Perhaps someone knows?

Best,
Peter


Brian


On 8/12/21 3:15 AM, Brian Dickson wrote:
 > This is the work I will be submitting in DNSOP.
 >
 > This is what has been described as a “hack”, but provides a needed 
validation link for authoritative servers where the latter are in signed zones, 
but where the served zones may not be signed.
 >
 > NB: It overlaps with the recent DPRIVE draft that Ben S submitted recently.
 >
 > It will likely be the case that those overlaps need to be reconciled, based 
on use cases and scope.
 >
 > I think there are valuable use cases other than privacy, which would make 
this more appropriate for DNSOP.
 >
 > Comments are welcome.
 >
 > The draft  can be found at:
 >
 >
 > https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-00.txt 
<https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-00.txt> 
<https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-00.txt 
<https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-00.txt>>
 >
 > Brian
 >
 > _______________________________________________
 > DNSOP mailing list
 > DNSOP@ietf.org <mailto:DNSOP@ietf.org>
 > https://www.ietf.org/mailman/listinfo/dnsop 
<https://www.ietf.org/mailman/listinfo/dnsop>
 >

--
Like our community service? 💛
Please consider donating at

https://desec.io/ <https://desec.io/>

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

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

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


--
Like our community service? 💛
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

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

Reply via email to