search

MelindaShore / dnssec-serialization

Internet draft(s) proposing a standard for serialization and transport of dnssec/dane validation chains
0 stars 1 forks source link

Server returns complete RR set? #12

Open MelindaShore opened 9 years ago

MelindaShore commented 9 years ago

From Viktor:

" I'm not sure what purpose the last paragraph of section 3 is intended to serve:

Obviously, an authentication chain will be most compact and easiest to verify if each RRset has a single record, i.e., if there is a single DNSKEY RR and a single DS RR at each step. In addition, as suggested above, keeping zone cuts to a minimum also reduces the length of the authentication chain.

The TLS server has no choice but to return the complete RRset for each owner name class and RRtype, since RRSIGs cover RRsets, not individual RRs. So "compacting" is possible. The server returns the RRsets exactly as published by the relevant DNS(SEC) servers.

Speaking of RRsets, are the RRs in each RRset returned by the server required to be sorted in canonical order"

MelindaShore commented 9 years ago

Related, he also says:

"The draft often says "TLSA record" when it needs to say "TLSA RRset". It will be quite common for multiple TLSA RRs to be present in the RRset, as this is required to correctly effect key rotation. Therefore, in Section 6 (and elsewhere), text such as the below:

If the record is correctly authenticated, the client then performs DANE authentication according to the DANE TLS protocol [RFC6698].

is sub-optimal, it should refer to a TLSA RRset, which MUST contain at least one TLSA record that matches the server's certificate chain, but will often contain additional records that do not."

shuque commented 9 years ago

Yes, Victor is correct. On the first point, DNS RRsets are returned atomically as a unit, and RRSIG signatures are computed over the entire RRset, so single or partial records from an RRset cannot be returned.

On the second point, RRs in an RRset do not need to returned in canonical order, as long as the verifier (client) sorts them canonically before signature computation. If the server does always return them in canonical order, then it will be less work for the client. But for implementers using DNS libraries, it will be easiest to produce and consume whatever order the libraries return and let them do the right thing. So it might be best to leave this unspecified.

On the third point, yes, the draft should mention RR sets rather than records where the former is correct.

I will send in some adjusted text for the 1st and 3rd points.

shuque commented 9 years ago

I believe there is one (slightly different) optimization we're planning to do involving only one RRSIG per RRSET. Some new text would be needed to describe that if so.