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