idnits 2.17.00 (12 Aug 2021) /tmp/idnits37877/draft-zhang-trans-ct-dnssec-01.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 62 has weird spacing: '...ponents of Ce...' -- The document date (December 23, 2014) is 2706 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '32' on line 297 == Outdated reference: draft-ietf-trans-rfc6962-bis has been published as RFC 9162 ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) ** Obsolete normative reference: RFC 4305 (Obsoleted by RFC 4835) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Zhang 3 Internet-Draft Huawei 4 Intended status: Experimental D. Gillmor 5 Expires: June 26, 2015 CMRG 6 D. He 7 Huawei 8 December 23, 2014 10 Certificate Transparency for Domain Name System Security Extensions 11 draft-zhang-trans-ct-dnssec-01 13 Abstract 15 In draft-ietf-trans-rfc6962-bis, a solution is proposed for publicly 16 logging the existence of Transport Layer Security (TLS) certificates 17 using Merkle Hash Trees. This document tries to use this idea in 18 DNSSEC and publicly logging the DS RRs in order to notice the 19 issuance of suspect key signing keys. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on June 26, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Cryptographic Components of Certificate Transparency . . . . 4 63 3. Motivation Scenario . . . . . . . . . . . . . . . . . . . . . 4 64 4. Log Format and Operation . . . . . . . . . . . . . . . . . . 5 65 4.1. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.2. Structure of the Signed Certificate Timestamp . . . . . . 6 67 4.3. Merkle Tree . . . . . . . . . . . . . . . . . . . . . . . 8 68 5. Including the Signed Certificate Timestamp into DNS Security 69 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5.1. SCT RR . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 5.1.1. The Key Tag Field . . . . . . . . . . . . . . . . . . 9 72 5.1.2. The Algorithm Field . . . . . . . . . . . . . . . . . 9 73 5.1.3. The Digest Type Field . . . . . . . . . . . . . . . . 10 74 5.1.4. The Digest Field . . . . . . . . . . . . . . . . . . 10 75 5.1.5. The SCT Field . . . . . . . . . . . . . . . . . . . . 10 76 5.1.6. The Signature Field . . . . . . . . . . . . . . . . . 10 77 5.2. Operations . . . . . . . . . . . . . . . . . . . . . . . 10 78 6. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 10 79 6.1. Add DNSSEC RR Chain to Log . . . . . . . . . . . . . . . 10 80 6.2. Retrieve Accepted Root DNSKEY RRs . . . . . . . . . . . . 11 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 8.1. Logging other types of RRs . . . . . . . . . . . . . . . 11 84 8.2. Scalability Concerns . . . . . . . . . . . . . . . . . . 12 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 86 10. Normative References . . . . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 89 1. Introduction 91 [I-D.ietf-trans-rfc6962-bis] specifies a Certificate Transparency 92 (CT) mechanism to disclosing TLS certificates into public logs so as 93 to benefit the public to monitor the operations in issuing 94 certificates to improper subscribers. The logs do not prevent mis- 95 issuing behavior directly, but the provided public audibility can 96 increase the possibility in detecting the improper behaviors of 97 issuers. The logs are constructed with Merkle Hash Trees to ensure 98 the append-only property, and thus enable anyone to verify the 99 correctness of each log. Note that CT is a common mechanism although 100 [I-D.ietf-trans-rfc6962-bis] only specify how to use it to publish 101 TLS server certificates issued by public certificate authorities 102 (CAs). 104 This document discusses the application of CT in addressing the 105 improper issuance issues in DNSSEC. DNSSEC establishes chains of 106 public keys for clients to assess the validity of DNS resource 107 records. In order to prove the validity of keys used for signing DNS 108 data, DNSSEC uses DNS public key (DNSKEY) RRsets and Delegation 109 Signer (DS) RRsets to form authentication chains for the signed data, 110 with each link in the chains vouching for the next by signing the 111 next. If an authentication chain can be eventually connected to the 112 a trusted DNS key or DS RR, the client can then ensure the key for 113 signing the data is legitimate. Unlike PKIX, SDNSEC inherently has 114 strong naming constraints. The owner of a zone can only be allowed 115 to sign the RRs in his zone. Any attempt in signing the RRs in other 116 zones will be easily detected by clients. However, the owner of a 117 zone is dependent on its parent delegation via the DS record to vouch 118 for its DNSKEY. The zone itself is responsible for publishing DS 119 records for the child zones that dependant on it. Misbehavior or 120 compromise of the parent zone directly affects the core DNS security 121 of the child zone. A detailed example is provided in Section 3. 123 In order to benefit the detection of improper issuance/delegation of 124 DNSSEC keys, this document describes an extension to CT to support 125 logging DSs . The CT logs are publicly auditable, making it possible 126 for anyone to verify the correctness of the log entries and monitor 127 the new DS RR's appended to the log. The logs do not prevent the 128 parent from issuing DS records that the child disagrees with, but 129 they ensure that interested parties can detect such operations. For 130 instance, For example, a zone owner that has been compromised or 131 compelled by a third party can hijack a child zone to return 132 different DNS data that is indistinguishable from DNSSEC validated 133 data from the child zone by using its own DNSKEY to sign DNS data on 134 behalf of the child zone. It could deliver this modified DNS data to 135 only selected regions or individuals, making this attack very 136 difficult to detect by the legitimate child zone. 138 In DNSSEC, it is assumed that the keys used for signing RRs or other 139 keys will be properly maintained. This work follows this assumption 140 and the compromise of key signing keys are out of scope of this work. 141 This work assumes the existence of inside attacker. That is, a legal 142 owner of a zone may try to attack or circumvent other zones. 143 However, because the naming constraint feature of DNSSEC, a zone 144 owner in principle can only use its keys to perform attacks on its 145 child zones. 147 This work reuses most of the messages and data structures specified 148 in [I-D.ietf-trans-rfc6962-bis] and makes necessary extensions for 149 supporting DS RRs. Only the extensions to 150 [I-D.ietf-trans-rfc6962-bis] are presented in this document. 152 2. Cryptographic Components of Certificate Transparency 154 The introduce of cryptographic components of CT is in Section 2 of 155 [I-D.ietf-trans-rfc6962-bis]. When applying CT for NDSSEC, a log is 156 a single, ever-growing, append-only Merkle Tree of DS RRs. 158 3. Motivation Scenario 160 Assume a zone (foo.bar.example) and its parent zone (bar.example) are 161 owned by different organizations. Follows are the steps of an 162 example attack that the owner of the parent zone could perform on the 163 child zone. 165 1. Set up a fake foo.bar.example DNS server 167 2. It generates a new key signing key X1 and zone signing key X2. 168 It uses the KSK to sign the ZSK. It uses the ZSK to sign its 169 resource records. 171 3. It generates a DS record for the KSK record it generated in step 172 2. 174 4. The owner of bar.example sign the DS RR with its zone signing key 175 and publishes it 177 5. Change the IP address of the DNS server of foo.bar.example in the 178 associated RRs to the IP address of the fake DNS server 180 The owner of foo.bar.example may try to periodically access the DNS 181 server of bar.example and monitor the RRs on it . However, there is 182 still a time window between two assessments which can be taken 183 advantage of by the owner of bar.example to perform a hijacking 184 attack and remove the bogus RRs before the owner of foo.bar.example 185 detects the attack. 187 In some cases, the parent can even achieve its objectives without 188 publishing the DS RR, which makes the attacks more difficult to 189 detect. 191 If the owner of bar.example is forced to publish his operations on 192 the public CT logs, any improper behaviors will be detected 193 eventually. Through checking the log, it is easy detect the improper 194 issuance of RRs of his parent zone. 196 4. Log Format and Operation 198 As illustrated in Section 3, a zone owner may need to publish 199 multiple RRs in order to hijack the queries to its child zone and re- 200 direct them to another illegal DNS server. However, it is not 201 necessary to publish all those associated RRs to the log. In fact, 202 by publishing the DS RR which is critical in constructing the 203 authentication chain across two zones will be sufficient for helping 204 the public to detect the improper issuance behavior. In this 205 solution, when a zone owner generates a DS RR and delegates a new 206 public key to a child zone, it MUST publish the DS RR at least one CT 207 log in order to allow the public to monitor its behavior. Identical 208 to what is specified in [I-D.ietf-trans-rfc6962-bis], each CT log 209 needs to return a SCT to the zone owner immediately. The SCT will be 210 encapsulated in a SCT RR and published within a DS RR. 212 The SCT is the log's promise to incorporate the RR in the Merkle Tree 213 within a fixed amount of time known as the Maximum Merge Delay (MMD). 214 If the log has previously seen the certificate, it MAY return the 215 same SCT as it returned before. DNS servers MUST provide an SCT 216 within a SCT RR. DNSSEC clients will not honor a DS RR that does not 217 have a valid SCT. Therefore it is expected that a zone owner will 218 usually deliver the DS RRs for audit purposes. 220 4.1. Log Entries 222 A zone owner can submit a DS RR to any preferred logs before 223 publishing the RR. In order to enable attribution of each logged RR 224 to its issuer, the log SHALL publish a list of acceptable public keys 225 (or hashes of public keys) of root zone or islands of security. Each 226 submitted DS RR MUST be accompanied by all additional RRs (DNSKEY 227 RRs, DS RRs, and RRSIG RRs) which construct an authentication chain 228 to an accepted root public key. 230 Logs MUST verify that the authentication chain and make sure it leads 231 back to a trusted public key, using the chain of intermediate DNSKEY 232 RRs and DS RRs provided by the submitter. Logs MUST refuse to 233 publish a DS RR without a valid chain to a trusted key. If a DS RR 234 is accepted and an SCT issued, the accepting log MUST store the 235 entire chain used for verification, including the DS RR itself and 236 including the trusted key used to verify the chain, and MUST present 237 this chain for auditing upon request. 239 To comply with the certificate entries specified in 240 [I-D.ietf-trans-rfc6962-bis],Each DS RR entry in a log MUST include 241 the following components: 243 enum { x509_entry(0), precert_entry(1), DSRR_entry(TBD1),(65535) } LogEntryType; 245 struct { 246 LogEntryType entry_type; 247 select (entry_type) { 248 case x509_entry: X509ChainEntry; 249 case precert_entry: PrecertChainEntry; 250 case DSRR_entry:DSRR_Chain_Entry 251 } entry; 252 } LogEntry; 254 opaque DNSSECRR<1..2^24-1>; 256 struct { 257 DNSSECRR DSRR; 258 DNSSECRR DNSSEC_key_chain<0..2^24-1> 259 } DSRR_Chain_Entry; 261 "entry_type" is the type of this entry. the type value of a DSRR 262 LogEntry is TBD. 264 "DSRR" is the DS RR submitted for auditing. 266 "DNSSEC_key_chain" is a chain of additional DNSSEC RRs required to 267 verify the DS RR.A typical authentication chain is as follow: Trusted 268 DNSSKEY ->[DS->(DNSKEY)*->DNSKEY]*-> Submitted DS RR, where "*" 269 denotes zero or more sub-chains. (DNSKEY)* indicates that DNSSEC 270 permits additional layers of DNSKEY RRs including the keys for 271 signing other keys within a zone. Each DNSKEY/DS RR in the chain is 272 authenticated by a RRSIG RR. In practice, a RRSIG RR is normally 273 used to sign a DS/DNSKEY RRset. Therefore, not only the DS/DNSKEY RR 274 on the authentication chain but also other records in the RRset 275 SHOULD be provided to the log the verification purpose. Otherwise, 276 the log may have to consult DNS again in order to verify the 277 authentication chains. Logs SHOULD limit the length of chain they 278 will accept. 280 4.2. Structure of the Signed Certificate Timestamp 282 This work reuses the structure of Signed Certificate Timestamp 283 specified in Section 3.3 of [I-D.ietf-trans-rfc6962-bis] but make 284 necessary extensions. 286 enum { certificate_timestamp(0), tree_hash(1),DSRR_timestamp(TBD2), (255) } 287 SignatureType; 289 enum { v1(0), (255) } 290 Version; 292 struct { 293 opaque key_id[32]; 294 } LogID; 296 struct { 297 opaque issuer_key_hash[32]; 298 C14N_DSRR dsrr; 299 } DSRR; 301 opaque CtExtensions<0..2^16-1>; 303 "key_id" and "issuer_key_hash" are defined in Section 3.3 of 304 [I-D.ietf-trans-rfc6962-bis]. 306 dsrr is the submitted DS RR in a canonical form. The 307 canconicalization of a DS RR is described in Section 6.2 of 308 [RFC4304]. 310 struct { 311 Version sct_version; 312 LogID id; 313 uint64 timestamp; 314 CtExtensions extensions; 315 digitally-signed struct { 316 Version sct_version; 317 SignatureType signature_type = DSRR_timestamp; 318 uint64 timestamp; 319 LogEntryType entry_type; 320 select(entry_type) { 321 case x509_entry: ASN.1Cert; 322 case precert_entry: PreCert; 323 case BIN_entry: BinaryDigest; 324 case BINDI_entry: BinaryDigest 325 } signed_entry; 326 CtExtensions extensions; 327 }; 328 } SignedCertificateTimestamp; 330 The encoding of the digitally-signed element is defined in [RFC5246]. 332 "sct_version", "timestamp", "entry_type and extensions" are are 333 identical to what is defined in Section 3.3 of 334 [I-D.ietf-trans-rfc6962-bis].. 336 "signed_entry" is the is DSRR (in the case of a DSRR_entry), as 337 described above. 339 "extensions" are future extensions to this protocol version (v1). 340 Currently, no extensions are specified. 342 4.3. Merkle Tree 344 This specification extends teh structure of the Merkle Tree input in 345 Section 3.5 of [I-D.ietf-trans-rfc6962-bis] and enable it to 346 encapsulate DS RR: 348 enum { v1(0), v2(1), (255) } 349 LeafVersion; 351 struct { 352 uint64 timestamp; 353 LogEntryType entry_type; 354 select(entry_type) { 355 case x509_entry: ASN.1Cert; 356 case precert_entry: PreCert; 357 case DSRR_entry: DSRR; 358 } signed_entry; 359 CtExtensions extensions; 360 } TimestampedEntry; 362 struct { 363 LeafVersion version; 364 TimestampedEntry timestamped_entry; 365 } MerkleTreeLeaf; 367 The fields in the input are introduced in Section 3.5 of 368 [I-D.ietf-trans-rfc6962-bis]. 370 Open question[dacheng]: We should include the RRs constucting the 371 authenticaiton chain in the input, right? 373 5. Including the Signed Certificate Timestamp into DNS Security 374 Extensions 376 In section 3.5 of [I-D.ietf-trans-rfc6962-bis] 378 5.1. SCT RR 380 The SCT associated with a DS RR is stored within a STC RR. A DNS 381 server MAY provide multiple SCT RRs for one DS RR. 383 The type number for the SCT record is TBD3. 385 The SCT resource record is class independent. 387 The life period of SCT RR should not be set in a way that the RR will 388 not be expired before the associated DS RR. 390 The RDATA portion of an SCT RR is as shown below. 392 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Key Tag | Algorithm | Digest Type | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 / / 398 / Digest / 399 / / 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 / / 402 / STC / 403 / / 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 / / 406 / Signature / 407 / / 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 5.1.1. The Key Tag Field 412 The Key Tag field lists the key tag of the DNSKEY RR referred to by 413 the SCT record, in network byte order. Appendix B of [RFC4034] 414 describes how to compute a Key Tag. 416 5.1.2. The Algorithm Field 418 The Algorithm field lists the algorithm number of the DNSKEY RR 419 referred to by the SCT record. Appendix A.1 of [RFC4034] lists the 420 algorithm number types. 422 5.1.3. The Digest Type Field 424 The Digest Type field identifies the algorithm used to construct the 425 digest used to identify the DS RR that the SCT RR refers to. 426 Appendix A.2 of [RFC4034] lists the possible digest algorithm types. 428 5.1.4. The Digest Field 430 The method of calculating digest is identical to what is specified in 431 Section 5.1.4 of [RFC2065].[RFC4034] 433 5.1.5. The SCT Field 435 This field contains the SCT got from the log, encoded in BASE64. 437 5.1.6. The Signature Field 439 This field contains the SCT signature associated with the SCT. The 440 Signature field is represented as a Base64 encoding of the signature. 442 5.2. Operations 444 After introducing the SCT RR, the verification procedures of DNS data 445 specified in DNSSEC[RFC4305] do not change a lot. However, the 446 correctness of CTS needs to be assessed during checking the validity 447 of a DS RR. 449 A DS RR needs to be associated with a CTS RR which contains a valid 450 CTS and signed with a proper public key. Otherwise, the DS RR will 451 not be used to construct the authentication chain. The signatures of 452 DS RR and its CTS RR should be stored in different RRSIG RR 453 respectively. In addition, a DNS server will sends CTS RRs and the 454 associated RRSIG RRs to a resolver only when it indicates the support 455 of CT in the request. 457 6. Log Client Messages 459 In Section 4 of [I-D.ietf-trans-rfc6962-bis], a set of messages is 460 defined for clients to query and verfiy the correctness of the log 461 entries they are interested in. In this memo, two new messages are 462 defined for CT to support DNSSEC. 464 6.1. Add DNSSEC RR Chain to Log 466 POST https:///ct/v1/add-RR-chain 468 Inputs: 470 chain: An array of base64-encoded DNS RR. The first element is 471 the submited DS RR; the second chains to the first and so on to 472 the last, which is a trurst DNSKey RR. 474 Outputs: 476 sct_version: The version of the SignedCertificateTimestamp 477 structure, in decimal. A compliant v1 implementation MUST NOT 478 expect this to be 0 (i.e., v1). 480 id: The log ID, base64 encoded. 482 timestamp: The SCT timestamp, in decimal. 484 extensions: An opaque type for future expansion. It is likely 485 that not all participants will need to understand data in this 486 field. Logs should set this to the empty string. Clients 487 should decode the base64-encoded data and include it in the 488 SCT. 490 signature: The SCT signature, base64 encoded. 492 6.2. Retrieve Accepted Root DNSKEY RRs 494 GET https:///ct/v1/get-root-RRs 496 No inputs. 498 Outputs: 500 RRs: An array of base64-encoded DNSKEY RRs that are acceptable to 501 the log. 503 7. IANA Considerations 505 8. Security Considerations 507 8.1. Logging other types of RRs 509 This solution only tries to describes a solution to disclose keys for 510 DNSSEC in logs for the public to audit. However, it may be valuable 511 to also log the RRs specified in [RFC1035]. For instance, assume 512 there is an attacker which has compromised the zone authentication 513 key and is able to perform the MITM attack between a resolver and the 514 DNS server of the zone. It is possible for an attacker to transfer a 515 forged RR which is signed with the compromised key. The current 516 solution cannot benefit the detection of this attack in this 517 scenario. However, if the RR is also required to be uploaded to 518 public logs, the condition is changed. If the attacker does not 519 publish the RR to a log, it cannot get the SCT. When the attacker 520 tries to publish the RR to the log, the owner of the zone may detect 521 the problem even if the attacker can provide keys to convince the log 522 to accept the RR. 524 8.2. Scalability Concerns 526 The log MAY limit accepting entries where the TTL is too short or the 527 RRSIG times are too far in the future or the past, to avoid spamming 528 the log. It should probably also put a maximum on the number of 529 child zones to avoid getting spammed. 531 9. Acknowledgements 533 10. Normative References 535 [I-D.ietf-trans-rfc6962-bis] 536 Laurie, B., Langley, A., Kasper, E., and R. Stradling, 537 "Certificate Transparency", draft-ietf-trans- 538 rfc6962-bis-04 (work in progress), July 2014. 540 [RFC1035] Mockapetris, P., "Domain names - implementation and 541 specification", STD 13, RFC 1035, November 1987. 543 [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security 544 Extensions", RFC 2065, January 1997. 546 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 547 Requirement Levels", BCP 14, RFC 2119, March 1997. 549 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 550 Rose, "Resource Records for the DNS Security Extensions", 551 RFC 4034, March 2005. 553 [RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to 554 IPsec Domain of Interpretation (DOI) for Internet Security 555 Association and Key Management Protocol (ISAKMP)", RFC 556 4304, December 2005. 558 [RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation 559 Requirements for Encapsulating Security Payload (ESP) and 560 Authentication Header (AH)", RFC 4305, December 2005. 562 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 563 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 565 Authors' Addresses 567 Dacheng Zhang 568 Huawei 570 Email: zhangdacheng@huawei.com 572 Daniel Kahn Gillmor 573 CMRG 575 Email: dkg@fifthhorseman.net 577 Danping He 578 Huawei 580 Email: ana.hedanping@huawei.com