idnits 2.17.1 draft-ietf-dane-protocol-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2011) is 4794 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'This' is mentioned on line 461, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft VPN Consortium 4 Intended status: Standards Track J. Schlyter 5 Expires: September 13, 2011 Kirei AB 6 March 12, 2011 8 Using Secure DNS to Associate Certificates with Domain Names For TLS 9 draft-ietf-dane-protocol-06 11 Abstract 13 TLS and DTLS use certificates for authenticating the server. Users 14 want their applications to verify that the certificate provided by 15 the TLS server is in fact associated with the domain name they 16 expect. DNSSEC provides a mechanism for a zone operator to sign DNS 17 information directly. This way, bindings of keys to domains are 18 asserted not by external entities, but by the entities that operate 19 the DNS. This document describes how to use secure DNS to associate 20 the TLS server's certificate with the intended domain name. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 13, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Certificate Associations . . . . . . . . . . . . . . . . . 3 58 1.2. Securing Certificate Associations . . . . . . . . . . . . 4 59 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Getting TLS Certificate Associations from the DNS . . . . . . 4 61 2.1. Requested Domain Name . . . . . . . . . . . . . . . . . . 5 62 2.2. Format of the Resource Record . . . . . . . . . . . . . . 5 63 2.3. Making Certificate Associations . . . . . . . . . . . . . 6 64 2.3.1. Format of Certificates Used to Identify End 65 Entities . . . . . . . . . . . . . . . . . . . . . . . 7 66 2.4. Presentation Format . . . . . . . . . . . . . . . . . . . 8 67 2.5. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 8 68 3. Use of TLS Certificate Associations in TLS . . . . . . . . . . 9 69 4. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 9 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 5.1. TLSA RRtype . . . . . . . . . . . . . . . . . . . . . . . 10 72 5.2. TLSA Certificate Types . . . . . . . . . . . . . . . . . . 10 73 5.3. TLSA Hash Types . . . . . . . . . . . . . . . . . . . . . 10 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 The first response from the server in TLS may contain a certificate. 84 In order for the TLS client to authenticate that it is talking to the 85 expected TLS server, the client must validate that this certificate 86 is associated with the domain name used by the client to get to the 87 server. Currently, the client must extract the domain name from the 88 certificate, must trust a trust anchor upon which the server's 89 certificate is rooted, and must successfully validate the 90 certificate. 92 Some people want a different way to authenticate the association of 93 the server's certificate with the intended domain name without 94 trusting a CA. Given that the DNS administrator for a domain name is 95 authorized to give identifying information about the zone, it makes 96 sense to allow that administrator to also make an authoritative 97 binding between the domain name and a certificate that might be used 98 by a host at that domain name. The easiest way to do this is to use 99 the DNS. 101 This document applies to both TLS [RFC5246] and DTLS [4347bis]. In 102 order to make the document more readable, it mostly only talks about 103 "TLS", but in all cases, it means "TLS or DTLS". This document only 104 relates to securely associating certificates for TLS and DTLS with 105 host names; other security protocols are handled in other documents. 106 For example, keys for IPsec are covered in [RFC4025] and keys for SSH 107 are covered in [RFC4255]. 109 1.1. Certificate Associations 111 In this document, a certificate association is based on a 112 cryptographic hash of a certificate (sometimes called a 113 "fingerprint") or on the certificate itself. For a fingerprint, a 114 hash is taken of the binary, DER-encoded certificate, and that hash 115 is the certificate association; the type of hash function used can be 116 chosen by the DNS administrator. When using the certificate itself 117 in the certificate association, the entire certificate in the normal 118 format is used. This document only applies to PKIX [RFC5280] 119 certificates. 121 Certificate associations are made between a certificate or the hash 122 of a certificate and a domain name. Server software that is running 123 TLS that is found at that domain name would use a certificate that 124 has a certificate association given in the DNS, as described in this 125 document. A DNS query can return multiple certificate associations, 126 such as in the case of different server software on a single host 127 using different certificates (even if they are normally accessed with 128 different host names), or in the case that a server is changing from 129 one certificate to another. 131 1.2. Securing Certificate Associations 133 This document defines a secure method to associate the certificate 134 that is obtained from the TLS server with a domain name using DNS 135 protected by DNSSEC. Because the certificate association was 136 retrieved based on a DNS query, the domain name in the query is by 137 definition associated with the certificate. 139 DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC4033], 140 [RFC4034], and [RFC4035]), uses cryptographic keys and digital 141 signatures to provide authentication of DNS data. Information 142 retrieved from the DNS and that is validated using DNSSEC is thereby 143 proved to be the authoritative data. The DNSSEC signature MUST be 144 validated on all responses in order to assure the proof of origin of 145 the data. 147 This document only relates to securely getting the DNS information 148 for the certificate association using DNSSEC; other secure DNS 149 mechanisms are out of scope. 151 1.3. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [RFC2119]. 157 A note on terminology: Some people have said that this protocol is a 158 form of "certificate exclusion". This is true, but only in the sense 159 that a DNS reply that contains two of the certificate types defined 160 here inherently excludes every other possible certificate in the 161 universe (other than those found with a pre-image attack against on 162 of those two). The certificate type defined here is better thought 163 of as "enumeration" of a small number of certificate associations, 164 not "exclusion" of a near-infinite number of other certificates. 166 Some of the terminology in this draft may not match with the 167 terminology used in RFC 5280. This will be fixed in future versions 168 of this draft, with help from the PKIX community. In specific, we 169 need to say (in a PKIX-appropriate way) that when we say "valid up 170 to" and "chains to", full RFC 5280 path processing including 171 revocation status checking is intended. 173 2. Getting TLS Certificate Associations from the DNS 175 This document defines a new DNS resource record type, "TLSA". A 176 query on a prepared domain name for the TLSA RR can return one or 177 more records of the type TLSA. The TLSA RRType is TBD. 179 2.1. Requested Domain Name 181 Domain names are prepared for requests in the following manner. 183 1. The decimal representation of the port number on which a TLS- 184 based service is assumed to exist is prepended with an underscore 185 character ("_") to become the left-most label in the prepared 186 domain name. 188 2. The protocol name of the transport on which a TLS-based service 189 is assumed to exist is prepended with an underscore character 190 ("_") to become the second left-most label in the prepared domain 191 name. The transport names defined for this protocol are "tcp", 192 "udp" and "sctp". 194 3. The domain name is appended to the result of step 2 to complete 195 the prepared domain name. 197 For example, to request a TLSA resource record for an HTTP server 198 running TLS on port 443 at "www.example.com", you would use 199 "_443._tcp.www.example.com" in the request. To request a TLSA 200 resource record for an SMTP server running the STARTTLS protocol on 201 port 25 at "mail.example.com", you would use 202 "_25._tcp.mail.example.com". 204 2.2. Format of the Resource Record 206 The format of the data in the resource record is a binary record with 207 three values, which MUST be in the order defined here: 209 o A one-octet value, called "certificate type", specifying the 210 provided association that will be used to match the target 211 certificate. This will be an IANA registry in order to make it 212 easier to add additional certificate types in the future. The 213 types defined in this document are: 215 1 -- A certificate that identifies an end entity 217 2 -- A certification authority's certificate 219 Both types are structured using the RFC 5280 formatting rules and 220 use the DER encoding. As described later in this document, type 1 221 certificates do not need to correctly use all PKIX semantics. 223 o A one-octet value, called "reference type", specifying how the 224 certificate association is presented. This value is defined in a 225 new IANA registry. The types defined in this document are: 227 0 -- Full certificate 229 1 -- SHA-256 hash of the certificate 231 2 -- SHA-512 hash of the certificate 233 Using the same hash algorithm as is used in the signature in the 234 certificate will make it more likely that the TLS client will 235 understand this TLSA data. 237 o The "certificate for association". This is the bytes containing 238 the full certificate or the hash of the associated certificate 239 (that is, the certificate or the hash of the certificate itself, 240 not of the TLS ASN.1Cert object). 242 Certificate types 1 and 2 explicitly only apply to PKIX-formatted 243 certificates. If TLS allows other formats later, or if extensions to 244 this protocol are made that accept other formats for certificates, 245 those certificates will need certificate types. 247 2.3. Making Certificate Associations 249 The two certificate types for TLS have very different semantics. A 250 TLS client conforming to this protocol receiving a certificate for 251 association of type 1 MUST compare it, using the specified hash type, 252 with the end entity certificate received in TLS. A TLS client 253 conforming to this protocol receiving a certificate for association 254 of type 2 MUST treat it as a trust anchor for that domain name. 256 Certificate type 1 (a certificate that identifies an end entity) is 257 matched against the first certificate offered by the TLS server. The 258 certificate for association is used only for exact matching, not for 259 chained validation. With reference type 0, the certificate 260 association is valid if the certificate in the TLSA data matches to 261 the first certificate offered by TLS. With reference types other 262 than 0, the certificate association is valid if the hash of the first 263 certificate offered by the TLS server matches the value from the TLSA 264 data. 266 Certificate type 2 (certification authority's certificate) can be 267 used in one of two ways. With reference type 0, the certificate in 268 the TLSA resource record is used in chaining from the end entity 269 given in TLS. The certificate association is valid if the first 270 certificate in the certificate bundle can be validly chained to the 271 trust anchor from the TLSA data. With reference types other than 0, 272 if the hash of any certificate past the first in the certificate 273 bundle from TLS matches the trust anchor from the TLSA data, and the 274 chain in the certificate bundle is valid up to that TLSA trust 275 anchor, then the certificate association is valid. Alternately, if 276 the first certificate offered chains to an existing trust anchor in 277 the TLS client's trust anchor repository, and the hash of that trust 278 anchor matches the value from the TLSA data, then the certificate 279 association is valid. 281 The end entity certificate from TLS, regardless of whether it was 282 matched with a TLSA type 1 certificate or chained to a TLSA type 2 CA 283 certificate, must have at least one identifier in the subject or 284 subjectAltName field of the matched certificates matches the expected 285 identifier for the TLS server. Further, the TLS session that is to 286 be set up MUST be for the specific port number and transport name 287 that was given in the TLSA query. The matching or chaining MUST be 288 done within the life of the TTL on the TSLA record. 290 2.3.1. Format of Certificates Used to Identify End Entities 292 When presented with a type 1 certificate, the TLS client MUST NOT 293 verify the correct PKIX semantics for the keyCertSign bit of the 294 keyUsage extension, nor of the the basicConstraints extension. This 295 is because PKIX (RFC 5280) makes it clear that all self-signed 296 certificates are CA certificates and cannot be end entity 297 certificates. The last paragraph of section 3.2 of RFC 5280 says: 299 "This specification covers two classes of certificates: CA 300 certificates and end entity certificates. CA certificates may be 301 further divided into three classes: cross-certificates, self-issued 302 certificates, and self-signed certificates. ... Self-issued 303 certificates are CA certificates in which the issuer and subject are 304 the same entity. ... Self-signed certificates are self-issued 305 certificates where the digital signature may be verified by the 306 public key bound into the certificate. Self-signed certificates are 307 used to convey a public key for use to begin certification paths. 308 End entity certificates are issued to subjects that are not 309 authorized to issue certificates." 311 This means that a self-signed certificate (one where the subject and 312 issuer are the same, and the public key in the certificate can be 313 used to directly evaluate the signature on the certificate) must 314 follow all the PKIX semantics rules for CAs, and probably need to 315 follow all the policy rules as well. This is clearly not what people 316 who want a simple way to associate their public signing key with 317 their domain name in an end entity certificate that can be used in 318 TLS. 320 Because of these PKIX requirements on end entity certificates, the 321 processing rules for TLSA are very different for certificates that 322 identify end entities directly and CA certificates that can be used 323 to validate PKIX end entity certificates. The rules here allow self- 324 signed certificates offered as type 1 certificates to not follow all 325 the PKIX semantics rules. 327 2.4. Presentation Format 329 The RDATA of the presentation format of the TLSA resource record 330 consists of two numbers (certificate and hash type) followed by the 331 bytes containing the certificate or the hash of the associated 332 certificate itself, presented in hex. An example of a SHA-256 hash 333 (type 1) of an end entity certificate (type 1) would be: 335 _443._tcp.www.example.com. IN TLSA ( 336 1 1 5c1502a6549c423be0a0aa9d9a16904de5ef0f5c98 337 c735fcca79f09230aa7141 ) 339 An example of an unhashed CA certificate (type 2) would be: 341 _443._tcp.www.example.com. IN TLSA ( 342 2 0 308202c5308201ada00302010202090... ) 344 Because the length of hashes and certificates can be quite long, 345 presentation format explicitly allows line breaks and white space in 346 the hex values; those characters are removed when converting to the 347 wire format. 349 2.5. Wire Format 351 The wire format is: 353 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 354 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Cert type | Hash type | / 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 358 / / 359 / Certificate for association / 360 / / 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 The wire format for the RDATA in the first example given above would 364 be: 366 _443._tcp.www.example.com. IN TYPE65534 \# 34 ( 01015c1502a6549c42 367 3be0a0aa9d9a16904de5ef0f5c98c735fcca79f09230aa7141 ) 369 The wire format for the RDATA in the second example given above would 370 be: 372 _443._tcp.www.example.com. IN TYPE65534 \# 715 0200308202c5308201a... 374 Note that in the preceding examples, "TYPE65534" is given as an 375 example. That RR Type is in the IANA "private use" range; the real 376 RR Type for TLSA will be issued by IANA, as described in the IANA 377 Considerations section below. 379 3. Use of TLS Certificate Associations in TLS 381 In order to use one or more TLS certificate associations described in 382 this document obtained from the DNS, an application MUST assure that 383 the certificates were obtained using DNS protected by DNSSEC. TLSA 384 records must only be trusted if they were obtained from a trusted 385 source. This could be a localhost DNS resolver answer with the AD 386 bit set, an inline validating resolver library primed with the proper 387 trust anchors, or obtained from a remote nameserver to which one has 388 a secured channel of communication. 390 If a certificate association contains a hash type that is not 391 understood by the TLS client, that certificate association MUST be 392 marked as unusable. 394 An application that requests TLS certificate associations using the 395 method described in this document obtains zero or more usable 396 certificate associations. If the application receives zero usable 397 certificate associations, it processes TLS in the normal fashion. 399 If a match between one of the certificate association(s) and the 400 server's end entity certificate in TLS is found, the TLS client 401 continues the TLS handshake. If no match between the usable 402 certificate association(s) and the server's end entity certificate in 403 TLS is found, the TLS client MUST abort the handshake with an 404 "access_denied" error. 406 4. Mandatory-to-Implement Algorithms 408 DNS systems conforming to this specification MUST be able to create 409 TLSA records containing certificate types 1 and 2. DNS systems 410 conforming to this specification MUST be able to create TLSA records 411 using hash type 0 (no hash used) and hash type 1 (SHA-256), and 412 SHOULD be able to create TLSA records using hash type 2 (SHA-512). 414 TLS clients conforming to this specification MUST be able to 415 correctly interpret TLSA records containing certificate types 1 and 416 2. TLS clients conforming to this specification MUST be able to 417 compare a certificate for association with a certificate from TLS 418 using hash type 0 (no hash used) and hash type 1 (SHA-256), and 419 SHOULD be able to make such comparisons with hash type 2 (SHA-512). 421 At the time this is written, it is expected that there will be a new 422 family of hash algorithms called SHA-3 within the next few years. It 423 is expected that some of the SHA-3 algorithms will be mandatory 424 and/or recommended for TLSA records after the algorithms are fully 425 defined. At that time, this specification will be updated. 427 5. IANA Considerations 429 5.1. TLSA RRtype 431 This document uses a new DNS RRType, TLSA, whose value is TBD. A 432 separate request for the RRType will be submitted to the expert 433 reviewer, and future versions of this document will have that value 434 instead of TBD. 436 5.2. TLSA Certificate Types 438 This document creates a new registry, "Certificate Types for TLSA 439 Resource Records". The registry policy is "RFC Required". The 440 initial entries in the registry are: 442 Value Short description Reference 443 ---------------------------------------------------------- 444 0 Reserved [This] 445 1 Certificate to identify an end entity [This] 446 2 CA's certificate [This] 447 3-254 Unassigned 448 255 Private use 450 Applications to the registry can request specific values that have 451 yet to be assigned. 453 5.3. TLSA Hash Types 455 This document creates a new registry, "Hash Types for TLSA Resource 456 Records". The registry policy is "Specification Required". The 457 initial entries in the registry are: 459 Value Short description Reference 460 --------------------------------------------- 461 0 No hash used [This] 462 1 SHA-256 NIST FIPS 180-3 463 2 SHA-512 NIST FIPS 180-3 464 3-254 Unassigned 465 255 Private use 467 Applications to the registry can request specific values that have 468 yet to be assigned. 470 6. Security Considerations 472 The security of the protocols described in this document relies on 473 the security of DNSSEC as used by the client requesting A/AAAA and 474 TLSA records. 476 A DNS administrator who goes rogue and changes both the A/AAAA and 477 TLSA records for a domain name can cause the user to go to an 478 unauthorized server that will appear authorized, unless the client 479 performs certificate validation and rejects the certificate. That 480 administrator could probably get a certificate issued anyway, so this 481 is not an additional threat. 483 The values in the TLSA data will be normally entered in the DNS 484 through the same system used to enter A/AAAA records, and other DNS 485 information for the host name. If the authentication for changes to 486 the host information is weak, an attacker can easily change any of 487 this information. Given that the TLSA data is not easily human- 488 readable, an attacker might change those records and A/AAAA records 489 and not have the change be noticed if changes to a zone are only 490 monitored visually. 492 If the authentication mechanism for adding or changing TLSA data in a 493 zone is weaker than the authentication mechanism for changing the 494 A/AAAA records, a man-in-the-middle who can redirect traffic to their 495 site may be able to impersonate the attacked host in TLS if they can 496 use the weaker authentication mechanism. A better design for 497 authenticating DNS would be to have the same level of authentication 498 used for all DNS additions and changes for a particular host. 500 SSL proxies can sometimes act as a man-in-the-middle for TLS clients. 501 In these scenarios, the clients add a new trust anchor whose private 502 key is kept on the SSL proxy; the proxy intercepts TLS requests, 503 creates a new TLS session with the intended host, and sets up a TLS 504 session with the client using a certificate that chains to the trust 505 anchor installed in the client by the proxy. In such environments, 506 the TLSA protocol will prevent the SSL proxy from functioning as 507 expected because the TLS client will get a certificate association 508 from the DNS that will not match the certificate that the SSL proxy 509 uses with the client. The client, seeing the proxy's new certificate 510 for the supposed destination will not set up a TLS session. 512 7. Acknowledgements 514 Many of the ideas in this document have been discussed over many 515 years. More recently, the ideas have been discussed by the authors 516 and others in a more focused fashion. In particular, some of the 517 ideas here originated with Paul Vixie, Dan Kaminsky, Jeff Hodges, 518 Phill Hallam-Baker, Simon Josefsson, Warren Kumari, Adam Langley, Ben 519 Laurie, Ilari Liusvaara, Scott Schmit, and Ondrej Sury. 521 8. References 523 8.1. Normative References 525 [4347bis] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 526 Security version 1.2", draft-ietf-tls-rfc4347-bis (work in 527 progress), July 2010. 529 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 530 Requirement Levels", BCP 14, RFC 2119, March 1997. 532 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 533 Rose, "DNS Security Introduction and Requirements", 534 RFC 4033, March 2005. 536 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 537 Rose, "Resource Records for the DNS Security Extensions", 538 RFC 4034, March 2005. 540 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 541 Rose, "Protocol Modifications for the DNS Security 542 Extensions", RFC 4035, March 2005. 544 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 545 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 547 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 548 Housley, R., and W. Polk, "Internet X.509 Public Key 549 Infrastructure Certificate and Certificate Revocation List 550 (CRL) Profile", RFC 5280, May 2008. 552 8.2. Informative References 554 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 555 Material in DNS", RFC 4025, March 2005. 557 [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely 558 Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, 559 January 2006. 561 Authors' Addresses 563 Paul Hoffman 564 VPN Consortium 566 Email: paul.hoffman@vpnc.org 568 Jakob Schlyter 569 Kirei AB 571 Email: jakob@kirei.se