Some of the Early KIDNS Proposals Jakob Schlyter, Kirei Paul - - PowerPoint PPT Presentation

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

• ther

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
• mnibus 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
• n 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