Hi - DNSSEC seems to be picking on PKIX and vice versa - maybe the right answer is both?
DNSSEC provides a "secure" association FROM the name TO the IP address. But the DNS domain owner tends not to be the host owner so this asserted association may not reflect the intent of the host owner. Also, DNSSEC doesn't protect from IP hijacking (re-routing). PKIX provides a "secure" association TO/FROM "a" name to a public key. The host owner holds the private key and can prove "ownership" of the related public key. But the host owner tends not to be the domain owner so the asserted association may not reflect the intent of the DNS domain owner. What if - the PKIX certificate for the host contained a "permit" for the name signed by the DNS owner? A signature over the hash of the public key in the certificate, and the DNS name - and maybe some expiration info verifiable by the data in DNSSEC? The path goes something like: 1) Use DNS and DNSSEC to find the host (or even just DNS) 2) Use TLS to grab the certificate 3) Verify the certificate using the PKIX path to a trust anchor 4) Verify the host knows the private key related to the host certificate 5) Verify the extension in the certificate was signed by the domain's DNSSEC key (pick one of special key, KSK or ZSK) 6) Verify the name offered in the certificate matches the DNS name looked up. You've verified that: a) The zone owner has assigned the name to the owner of the cert's private key b) The host owner has agreed the host has the DNS name. c) The IP to Name mapping (what might be in the PTR record and signed under DNSSEC - maybe). The DNSSEC name to IP address mapping becomes irrelevant for trust purposes which means that IP hijacking is no longer an issue. A random PKIX forming a certificate with a DNS name in it can't form one that proves the name assignment from the DNS, so the large set of PKIX trust anchors becomes less of an issue. Mike _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
