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