Some of the Early KIDNS Proposals Jakob Schlyter, Kirei Paul Hoffman, VPN Consortium v04 1
Introduction • Purpose: to help the eventual WG choose what to include in its deliverables • This is a partial list of the many proposals so far, not a proposal – Many things described here contradict each other 2
Ideas so far • Drafts in the proposed charter – draft-hallambaker-certhash – draft-hoffman-keys-linkage-from-dns – draft-josefsson-keyassure-tls • More recently – draft-hallambaker-donotissue – draft-turner-dnssec-centric-pki • And, more importantly, lots of discussion on the mailing list 3
Definitions • Certificate / cert: any format • Xyz certificate: a cert specifically in the Xyz format (such as PKIX) • CA certificate: a cert that says “I am trusted to identify end entities” • EE: end-entity, normally the system that is at the domain name being asked about 4
Exclusion and specification • Early discussion in this area talked about “certificate exclusion” – Main threat discussed was excluding a CA that is in everyone’s trust anchor pile but issues a cert it should not • Most proposals are for “specification”: only accept { exactly this { key | cert } | a cert that chains to exactly this CA } – Similar to what we have today with SSH/SSHFP 5
Motivations • DNS (or DNSSEC) lookup followed by TLS negotiation and certificate validation can have long latency – OCSP, CRL lookup, and so on • Typical PKIX certificate validation (“DV validation”) has known security issue: if you trust one CA, you trust them all • Proposed solution: use DNSSEC to allow the host to declare what public key it uses – Can even save a bit of time by doing the DNS lookup in parallel with TLS 6
Ways of identifying keys • The key itself • A hash of the key • The key in a self-signed EE cert • A hash of (the key in a self-signed EE cert) • A hash of (the key in a CA-rooted EE cert) • A hash of (a CA cert that is expected to be in the user’s trust anchor store) • The CA cert itself – see next presentation 7
Semantics of a key or hash-of-key • This will be the key that will be offered in the protocol – The protocol will offer either the key itself or the key as part of an EE cert • If you don’t see this key in the protocol, stop: there is a security problem • See SSHFP and IPSECKEY as examples 8
Semantics of hash-of-EE-cert (1) • This will be the certificate that will be offered in the protocol • If you don’t see this cert in the protocol, stop: there is a security problem • If this is a self-signed cert, { probably | definitely } don’t try to validate it • If this is a CA-rooted cert, { maybe | definitely } try to validate it 9
Semantics of hash-of-EE-cert (2) • Speed of validation is an issue – Not just CPU speed, but also the time it takes to get a CRL or OCSP response or SCVP response – It is reasonable for a client to have a policy of “just trust the DNS data” if it is secure • There may be other info you care about inside the cert, such as an EV name • The server cannot demand a local validation policy, and probably should not even suggest one 10
Semantics of hash-of-CA-cert • This is the only CA cert that I want you to chain to for the certificate that will be offered in the protocol • If you don’t have this CA cert in your trust anchor pile, stop: you { SHOULD | MUST } NOT validate my EE cert • If you do have this CA cert in your trust anchor pile, validate the EE cert that I am presenting 11
Semantics of CA cert itself • See next presentation • Not similar to any of the ones listed so far • Older proposal: draft-schlyter-pkix-dns 12
Associating a key with an application / port • The key can be associated with all secure services running on a host with a single domain name; this requires different domain names for different keys • Associated with the application running on a specified port (doesn’t work for IPsec) – Can be specified in the response: a request to example.com gives back each answer containing the specific port number in addition to the key material – Can be specified in the request: _443.example.com and _993.example.com each gives back one answer – Maybe also differentiate on transports (TCP vs. UDP) 13
Allowing more than one certificate per host name • Example: https://www.bofa.com gives different certs at different times • Few sites do this, but it is not zero • Should try to allow this use case 14
Application clients who don’t know whether or not DNSSEC is in use • The vast majority of applications today have no idea if the DNS queries they make have their responses covered by DNSSEC • If a client gets replies back but cannot tell if they were secure, what does that mean for the protocol? • In short: does the protocol make things worse if DNSSEC is not used? 15
Algorithm agility • Should be agility for any hash used • Should allow any signature algorithm 16
Certificate format agility • Some proposals have been neutral to the certificate format: can use PKIX, OpenPGP, ... • Others have been PKIX-only in order to get PKIX-specific information from the cert 17
Just TLS, or all security protocols? • TLS requires a certificate, other protocols have certificates optional • Every protocol has keys, but not all have certificates (such as SSH) • One document per security protocol vs. and omnibus document will probably be a matter of taste • Some of this could apply to IPsec, but interoperable certificate usage there is low anyway 18
Operational considerations • DNS admins should accept key signing requests through the same channels now used to accept/approve A records, that is, from the same trusted people • DNS admins cannot (and should not) try to validate the certificate’s validity in any way • There are issues with revocation/expiry, but the solution is the same as for other DNS records: just remove the record – DNS caches present a bit of complexity here 19
Format of the DNS record • Create our own RRType, sub-class CERT, or use TXT with a _prefix • It only matters operationally: it affects adoption by people using older DNS servers • There is little agreement on how bad or not bad the operational problem is • Nearly everyone has a religious favorite • This can be decided after the more interesting parts are defined 20
Everyone has the DNS format problem • Can ameliorate by having example Perl / Python code in an appendix of how to create the records • Can even have a soon-to-be outdated guide on how to implement in popular DNS servers • Really: this is probably less important than you think 21
Problem statement • There is disagreement from some folks about which problems are meant to be solved • Can either create a separate problem statement document or put the problem statement in the protocol document 22
Policy • The topic keeps coming back • We probably have to deal with it, or at least avoid it openly • Proposal: security statements that are mandatory can be given outside the security protocol, but security preferences that are at all optional should not be 23
Conformance statements • Most specifications say what you MUST / SHOULD do in order to conform to the protocol • Some people feel that you cannot tell an application what it must do with respect to its security posture • Is a security protocol with no mandatory semantics worthwhile? 24
The last slide • This usually says “questions?” and has a humorous piece of clip-art, but most things said at the mic are statements and are not humorous 25
Recommend
More recommend
