On 4/12/21 9:14 AM, Nico Williams wrote:
On Mon, Apr 12, 2021 at 09:02:57AM -0700, Michael Thomas wrote:
On 4/12/21 8:51 AM, Nico Williams wrote:
You get better security properties (w.r.t. possible compromised root or
ccTLD/TLD keys) if the resolver finds the DNSSEC chain on its own using
qname minimization than you get with stapling, but I agree that stapling
is a performance win. We'll really want transparency for DNSSEC if we
do any kind of full chain stapling.
Can somebody explain what "stapling" is?
In general "stapling" means sending all the ancilliary things that the
peer would otherwise have to lookup on its own to save it the bother.
So:
- "OCSP" == RP sends request to OCSP Responder
- "stapled OCSP" == supplicant sends its EE cert and chain and cached
OCSPResponse to the RP so the RP need not go talk to an OCSP
Responder
- "DANE" == RP looks up all the relevant RRs needed to validate
supplican't certificate
- "stapled DANE" == supplicant sends TLSA RRs and DNSSEC chain along
with its certificate so that the RP need not perform those lookups
separately
(RP == relying party)
(supplicant == the entity authenticated by the end-endity certificate it
presents to the RP)
Ah, thanks. I was guessing it might be that. I assume it goes into the
Additional RR's like SoA records. Are there rules on what a can be
supplied as additional RR's? Is the client allowed to supply hints or
does the DNS server have to just guess?
Mike
