idnits 2.17.00 (12 Aug 2021) /tmp/idnits57237/draft-housley-evidence-extns-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 869. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 846), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Either party may initiate the closure of an evidence-creating interval and the exchange of evidence messages by sending the evidence_end1 alert. Upon sending evidence_end1, the sender MUST not send any more application data on this connection until the Evidence Protocol messages are exchanged. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '2' on line 223 == Missing Reference: 'TLSAUTHZ' is mentioned on line 511, but not defined == Missing Reference: 'RANDOM' is mentioned on line 681, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' ** Obsolete normative reference: RFC 2313 (ref. 'PKCS1') (Obsoleted by RFC 2437) ** Obsolete normative reference: RFC 3280 (ref. 'PKIX1') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4366 (ref. 'TLSEXT') (Obsoleted by RFC 5246, RFC 6066) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' == Outdated reference: draft-housley-tls-authz-extns has been published as RFC 5878 -- Obsolete informational reference (is this intentional?): RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft M. Brown 3 August 2006 RedPhone Security 4 Expires: February 2007 R. Housley 5 Vigil Security 7 Transport Layer Security (TLS) Evidence Extensions 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2006). All Rights Reserved. 37 Abstract 39 This document specifies evidence creation extensions to the Transport 40 Layer Security (TLS) Protocol. Extension types are carried in the 41 client and server hello message extensions to confirm that both 42 parties support the protocol features needed to perform evidence 43 creation. The syntax and semantics of the evidence creation alerts 44 and messages are described in detail. 46 1. Introduction 48 Transport Layer Security (TLS) protocol [TLS1.0][TLS1.1] is being 49 used in an increasing variety of operational environments, including 50 ones that were not envisioned when the original design criteria for 51 TLS were determined. The extensions specified in this document 52 support evidence creation in environments where the peers in the TLS 53 session cooperate to create persistent evidence of the TLS-protected 54 application data. Such evidence may be necessary to meet business 55 requirements, including regulatory requirements. Also, evidence may 56 be used in tandem with authorization information to make high 57 assurance access control and routing decisions in military and 58 government environments. Evidence created using this extension may 59 also be used to audit various aspects of the TLS handshake, including 60 the cipher suite negotiation and the use of other TLS extensions. In 61 many cases, the evidence does not need to be validated by third 62 parties; however, in other cases, the evidence might be validated by 63 third parties. To accommodate all of these situations, the evidence 64 is generated using a digital signature. Since validation of a 65 digital signature requires only public information, evidence 66 generated with this mechanism is suitable for sharing with third 67 parties. 69 When digital certificates are to be employed in evidence creations, 70 the client must obtain the public key certificate (PKC) for the 71 server, and the server must obtain the PKC for the client. This is 72 most easily accomplished by using the PKCs provided in the Handshake 73 Protocol Certificate messages. Further, both parties SHOULD have an 74 opportunity to validate the PKC that will be used by the other party 75 before evidence creation. Again, this is naturally accomplished 76 using the Handshake Protocol, where the TLS session can be rejected 77 if the PKC cannot be validated. 79 This document describes evidence creation TLS extensions supporting 80 both TLS 1.0 and TLS 1.1. These extensions observe the conventions 81 defined for TLS Extensions [TLSEXT]. The extensions are designed to 82 be backwards compatible, meaning that the protocol alerts and 83 messages associated with the evidence creation extensions will be 84 exchanged only if the client indicates support for them in the client 85 hello message and the server indicates support for them in the server 86 hello message. 88 Clients typically know the context of the TLS session before it is 89 established. As a result, the client can request the use of the 90 evidence creation extensions in sessions where they might be needed. 91 Servers accept extended client hello messages, even if the server 92 does not support the all of the listed extensions. However, the 93 server will not indicate support for any extensions that are not 94 "understood" by the implementation. At the end of the hello message 95 exchange, the client may reject communications with servers that do 96 not support the evidence creation extensions, or the client may 97 accept the situation and proceed, whichever is appropriate. 99 1.1. Conventions 101 The syntax for the evidence creation messages is defined using the 102 TLS Presentation Language, which is specified in Section 4 of 103 [TLS1.0]. 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [STDWORDS]. 109 1.2. Overview 111 Figure 1 illustrates the placement of the evidence creation alerts 112 and messages in the TLS session. The first pair of evidence creation 113 alerts indicates the beginning of the protected content that will be 114 covered by the evidence. The first pair of alerts can appear any 115 place after the TLS Handshake Protocol Finished messages, which 116 ensures that they are integrity protected. The second pair of 117 evidence creation alerts indicates the ending of the protected 118 content that will be covered by the evidence. Immediately after the 119 reception of the final alert, a pair of Evidence Protocol messages is 120 exchanged to create the persistent evidence. 122 Generating evidence is not compatible with Diffie-Hellman Ephemeral 123 (DHE) key exchanges. DHE does not permit the same keying material to 124 be generated for validation of the evidence after the TLS session is 125 over. Persistent evidence requires the use of a digital signature so 126 that it can be validated well after the TLS session is over. 128 The ClientHello message includes an indication that the evidence 129 creation messages are supported. The ServerHello message also 130 includes an indication that the evidence creation messages are 131 supported. Both the client and the server MUST indicate support for 132 the evidence protocol alerts and messages; otherwise they MUST NOT be 133 employed by either the client or the server. 135 Client Server 137 ClientHello --------> 138 ServerHello 139 Certificate+ 140 ServerKeyExchange* 141 CertificateRequest+ 142 <-------- ServerHelloDone 143 Certificate+ 144 ClientKeyExchange 145 CertificateVerify+ 146 ChangeCipherSpec 147 Finished --------> 148 ChangeCipherSpec 149 <-------- Finished 150 Application Data <-------> Application Data 151 Alert(evidence_start1) --------> 152 Application Data 153 <-------- Alert(evidence_start2) 155 Application Data <-------> Application Data 156 Alert(evidence_end1) --------> 157 Application Data 158 <-------- Alert(evidence_end2) 159 EvidenceRequest --------> 160 <-------- EvidenceResponse 161 Application Data <-------> Application Data 163 * Indicates optional or situation-dependent messages that 164 are not always sent. 165 + Indicates messages optional to the TLS handshake that 166 MUST be sent when using TLS evidence. 168 Figure 1. Example TLS Session with Evidence Creation. 170 2. Evidence Extension Types 172 The general extension mechanisms enable clients and servers to 173 negotiate whether to use specific extensions, and how to use specific 174 extensions. As specified in [TLSEXT], the extension format used in 175 the extended client hello message and extended server hello message 176 within the TLS Handshake Protocol is: 178 struct { 179 ExtensionType extension_type; 180 opaque extension_data<0..2^16-1>; 181 } Extension; 183 The extension_type identifies a particular extension type, and the 184 extension_data contains information specific to the particular 185 extension type. 187 As specified in [TLSEXT], for all extension types, the extension type 188 MUST NOT appear in the extended server hello message unless the same 189 extension type appeared in the preceding client hello message. 190 Clients MUST abort the handshake if they receive an extension type in 191 the extended server hello message that they did not request in the 192 preceding extended client hello message. 194 When multiple extensions of different types are present in the 195 extended client hello message or the extended server hello message, 196 the extensions can appear in any order, but there MUST NOT be more 197 than one extension of the same type. 199 This document specifies the use of the evidence_creation extension 200 type. This specification adds one new type to ExtensionType: 202 enum { 203 evidence_creation(TBD), (65535) 204 } ExtensionType; 206 The evidence_creation extension is relevant when a session is 207 initiated and also for any subsequent session resumption. However, a 208 client that requests resumption of a session does not know whether 209 the server has maintained all of the context necessary to accept this 210 request, and therefore the client SHOULD send an extended client 211 hello message that includes the evidence_creation extension type. 212 This indicates that the client requests the server's continued 213 cooperation in creating evidence. If the server denies the 214 resumption request, then the evidence_creation extension will be 215 negotiated normally using the full Handshake protocol. 217 Clients MUST include the evidence_creation extension in the extended 218 client hello message to indicate their desire to send and receive 219 evidence creation alerts and messages. The extension_data field 220 indicates the evidence creation algorithms that are supported. The 221 format is indicated with the EvidenceCreateList type: 223 uint16 EvidenceCreateSuite[2]; 225 struct { 226 EvidenceCreateSuite evidence_suites<2..2^16-1>; 227 } EvidenceCreateList; 229 The EvidenceCreateList enumerates the evidence creation algorithms 230 that are supported by the client. The client MUST order the entries 231 from most preferred to least preferred, but all of the entries MUST 232 be acceptable to the client. Values are defined in Appendix A, and 233 others can be registered in the future. 235 Servers that receive an extended client hello message containing the 236 evidence_creation extension MUST respond with the evidence_creation 237 extension in the extended server hello message if the server is 238 willing to send and receive evidence creation alerts and messages. 239 The evidence_creation extension MUST be omitted from the extended 240 server hello message if the server is unwilling to send and receive 241 using one of the evidence creation algorithm suites identified by the 242 client. The extension_data field indicates the evidence creation 243 algorithm suite that the server selected from the list provided by 244 the client. The format is indicated with the EvidenceCreateSuite 245 type defined above. 247 3. Alert Messages 249 This document specifies the use of four new alert message 250 descriptions: the evidence_start1, evidence_start2, evidence_end1, 251 and evidence_end2. These descriptions are specified in Sections 3.1, 252 3.2, 3.3, and 3.4, respectively. The alert descriptions are 253 presented below in the order they MUST be sent; sending alerts in an 254 unexpected order results in a fatal error. These descriptions are 255 always used with the warning alert level. This specification adds 256 four new types to AlertDescription: 258 enum { 259 evidence_start1(TBD), 260 evidence_start2(TBD), 261 evidence_end1(TBD), 262 evidence_end2(TBD), 263 evidence_failure(TBD), 264 (255) 265 } AlertDescription; 267 3.1. The evidence_start1 Description 269 The client and the server need to synchronize evidence creation. 270 Either party may initiate the desire to start creating evidence by 271 sending the evidence_start1 alert. If the other party is ready to 272 begin creating evidence, then the other party MUST send an 273 evidence_start2 alert in response to the evidence_start1 alert that 274 was sent. If the other party is unwilling to begin creating 275 evidence, the other party MUST respond with fatal 276 evidence_failure(TBD) alert and terminate the TLS session. 278 Digital signatures are used in evidence creation. If an 279 evidence_start1 alert is received before the other party has provided 280 a valid PKC, then the evidence_start1 alert recipient MUST terminate 281 the TLS session using a fatal certificate_unknown alert. 283 3.2. The evidence_start2 Description 285 The evidence_start2 alert is sent in response to the evidence_start1 286 alert. By sending the evidence_start2 alert, the sending party 287 indicates that they are also ready to begin creating evidence. After 288 this pair of alerts is exchanged, both the client and the server use 289 the hash function indicated in the extended server hello message to 290 start computing the evidence. Each party computes two independent 291 hash values: one for each octet that is written, and one for each 292 octet that is read. 294 Digital signatures are used in evidence creation. If an 295 evidence_start2 alert is received before the other party has provided 296 a valid PKC, then the evidence_start2 alert recipient MUST terminate 297 the TLS session using a fatal certificate_unknown alert. 299 3.3. The evidence_end1 Description 301 Either party may initiate the closure of an evidence-creating 302 interval and the exchange of evidence messages by sending the 303 evidence_end1 alert. Upon sending evidence_end1, the sender MUST not 304 send any more application data on this connection until the Evidence 305 Protocol messages are exchanged. 307 The evidence_end1 alert sender MAY initiate the Evidence Protocol as 308 described in Section 4 at any time following this alert. The 309 evidence_end1 alert sender SHOULD ensure that it has received all 310 pending application data writes from the other party before 311 initiating the Evidence Protocol. One way to ensure that all of the 312 application data has been received it to wait for the receipt of an 313 evidence_end2 alert. If the Evidence Protocol begins before all of 314 the application data is available, the result will be a fatal 315 evidence_failure(TBD) alert when signature verification fails. 317 3.4. The evidence_end2 Description 319 The evidence_end2 alert is sent in response to the evidence_end1 320 alert. The evidence_end1 alert receiver SHOULD complete any pending 321 writes. The intent is to include any application data that would be 322 sent in response to application data that was received before the 323 evidence_end1 alert as part of evidence creation. Once the pending 324 writes are complete, the evidence_end1 alert receiver sends the 325 evidence_end2 alert. 327 At this point, each party completes the hash value computations. 329 The evidence_end2 alert receiver MUST respond by initiating the 330 Evidence Protocol as described in Section 4, if it has not already 331 done so. 333 3.5. The evidence_failure Description 335 The evidence_failure fatal alert is sent to indicate a failure in 336 evidence creation. During evidence synchronization, this alert 337 indicates that the sending party is unwilling to begin evidence 338 creation. During the Evidence Protocol, this alert indicates that 339 the evidence provided by the other party is not acceptable or cannot 340 be validated. 342 4. Evidence Protocol 344 This document specifies an additional TLS Protocol: the Evidence 345 Protocol. It is used to create persistent evidence of the TLS 346 session content. This specification adds one new Record layer 347 ContentType: 349 enum { 350 evidence(TBD), 351 (255) 352 } ContentType; 354 Persistence evidence of the TLS session content is produced by the 355 TLS Evidence Protocol. Evidence messages are supplied to the TLS 356 Record Layer, where they are encapsulated within one or more 357 TLSPlaintext structures, which are processed and transmitted as 358 specified by the current active session state. 360 The Evidence Protocol structure follows: 362 enum { 363 request(1), response(2), (255) 364 } EvidenceMsgType; 366 struct { 367 EvidenceMsgType evidence_msg_type; 368 uint24 length; /* number of octets in message */ 369 select (EvidenceMsgType) { 370 case request: EvidenceRequest; 371 case response: EvidenceResponse; 372 } body; 373 } EvidenceProtocol; 375 The Evidence Protocol messages are presented below in the order they 376 MUST be sent; sending evidence messages in an unexpected order 377 results in a fatal unexpected_message(10) alert. The EvidenceRequest 378 message and the EvidenceResponse message are specified in Section 4.2 379 and Section 4.3, respectively. Section 4.1 describes structures that 380 are used in the EvidenceRequest and EvidenceResponse messages. 382 4.1. Certificates and Digital Signatures 384 The evidence Protocol makes use of the ASN.1Cert definition used 385 elsewhere in TLS. It is repeated here for convenience. 387 opaque ASN.1Cert<1..2^24-1>; 389 The EvidenceSignature definition is very similar to the Signature 390 definition used elsewhere in TLS. The EvidenceSignature definition 391 signs hash[hash_size], but the Signature definition used elsewhere in 392 TLS signs a combination of an md5_hash and a sha_hash. Also, the 393 EvidenceSignature definition excludes the anonymous case. 395 enum { rsa, dsa, ecdsa } EvidenceSignatureAlgorithm; 397 select (EvidenceSignatureAlgorithm) 398 { case rsa: 399 digitally-signed struct { 400 opaque hash[hash_size]; 401 }; 402 case dsa: 403 digitally-signed struct { 404 opaque hash[hash_size]; 405 }; 406 case ecdsa: 407 digitally-signed struct { 408 opaque hash[hash_size]; 409 }; 410 } EvidenceSignature; 412 The hash algorithm and the hash_size depend on evidence create 413 algorithm suite selected by the server in the evidence_creation 414 extension. 416 4.2. EvidenceRequest Message 418 The EvidenceRequest message contains the evidence_end1 alert sender's 419 contribution to the persistent evidence. It employs the evidence 420 create algorithm suite selected by the server in the 421 evidence_creation extension in the extended server hello message. 423 struct { 424 Evidence evidence<1..2^16-1>; 425 ASN.1Cert party1_certificate; 426 EvidenceSignature party1_signature; 427 } EvidenceRequest; 429 struct { 430 EvidenceCreateSuite evidence_suite; 431 uint32 gmt_unix_time; 432 opaque handshake_protocol_hash<1..512>; 433 opaque app_data_sent_hash<1..512>; 434 opaque app_data_received_hash<1..512>; 435 } Evidence; 437 The elements of the EvidenceRequest structure are described below: 439 evidence 440 Contains an evidence create algorithm identifier, a timestamp, 441 and three hash values in the Evidence structure as described 442 below. 444 party1_certificate 445 Contains the X.509 certificate of the signer. While this 446 certificate was probably exchanged and validated in the 447 Handshake Protocol, inclusion here makes it clear which 448 certificate was employed by the signer when the evidence is 449 validated in the future, possibly by a third party. 451 party1_signature 452 Contains the digital signature computed by the sender of the 453 evidence_end1 alert using the evidence creation algorithm suite 454 identified in evidence_create_suite. The hash value is 455 computed as: 457 Hash(evidence) 459 The elements of the Evidence structure are described below: 461 evidence_suite 462 Indicates the evidence creation algorithm suite selected by the 463 server in the evidence_creation extension in the Handshake 464 Protocol. This value determines the structure of the hash 465 values and digital signatures. 467 gmt_unix_time 468 Indicates the current date and time according to the local 469 system clock used by the sender of the evidence_end1 alert. 470 This time value is intended to represent the moment in time 471 that evidence_end1 was sent. 473 handshake_protocol_hash 474 Compute as: 476 Hash(handshake_messages), 478 where handshake_messages refers to all Handshake Protocol 479 messages sent or received, beginning with the most recent 480 client hello message. If the double handshake mechanism 481 described in the security considerations of [TLSAUTHZ] is used 482 to encrypt the Handshake Protocol, the plaintext form of these 483 messages is used in calculating this hash value. 485 Verification of the handshake_protocol_hash is performed using 486 the plaintext form of the Handshake protocol messages. For 487 this hash value to be validated at a later time, this 488 information must be saved as part of the overall evidence. Any 489 attempt to save this data must ensure that it is not 490 inappropriately disclosed by employing suitable physical 491 protection or cryptographic mechanisms that are at least as 492 strong as the selected TLS ciphersuite. Suitable controls are 493 discussed further in the Security Considerations; see Section 494 6. 496 In the case of successful TLS session resumption, the most 497 recent client hello message will contain a valid 498 ClientHello.session_id value as well as extensions, and these 499 extensions may include sensitive data. The TLS Authorization 500 Extension [AUTHZ] is one example where an extension might 501 contain sensitive information. Thus, even when session 502 resumption is employed, the content of the Handshake protocol 503 messages ought to be protected. 505 TLS users should ensure that the content of the Handshake 506 protocol messages contain sufficient evidence to determine the 507 intent of the signers, where "signers" are defined as the 508 subject identities in the exchanged X.509 certificates. 509 Clients and servers MAY record the protocol messages containing 510 an expression of the intent of the signers using a suitable TLS 511 extension [TLSEXT], such as [TLSAUTHZ]. For example, a client 512 may request access to a resource provided by the server, 513 provide sufficient authentication and authorization information 514 grounds to convince the server to grant the requested access, 515 and receive an affirmative response from the server. A record 516 of TLS Handshake protocol messages representing this example 517 may provide a sufficient record of the intent of both the 518 client and the server. 520 app_data_sent_hash 521 Compute as: 523 Hash(sent_application_data), 525 where sent_application_data refers to all of the Application 526 Data messages sent since the most recent evidence_start1 or 527 evidence start2 alert was sent, and ending with the sending of 528 the evidence_end1 alert. The alerts are not application data, 529 and they are not included in the hash computation. 531 app_data_received_hash 532 Compute as: 534 Hash(received_application_data), 536 where received_application_data refers to all of the 537 Application Data messages received since the most recent 538 evidence_start1 or evidence start2 alert was received, and 539 ending with the receipt of the evidence_end2 alert. The alerts 540 are not application data, and they are not included in the hash 541 computation. 543 4.3. EvidenceResponse Message 545 The EvidenceResponse message contains the complete persistent 546 evidence. The value is saved by one or both parties as evidence of 547 the TLS session content identified by the evidence_start1, 548 evidence_start2, evidence_end1, and evidence_end2 alerts. 550 struct { 551 Evidence evidence<1..2^16-1>; 552 ASN.1Cert party1_certificate; 553 EvidenceSignature party1_signature; 554 ASN.1Cert party2_certificate; 555 EvidenceSignature party2_signature; 556 } EvidenceResponse; 558 The elements of the EvidenceResponse structure are described below: 560 evidence 561 Contains an evidence create algorithm identifier, a timestamp, 562 and three hash values in the Evidence structure as described in 563 section 4.2. The evidence creation algorithm MUST match the 564 evidence create algorithm suite selected by the server in the 565 evidence_creation extension in the extended server hello 566 message. The timestamp MUST be acceptable to the 567 EvidenceRequest recipient. The three hash values MUST be match 568 locally computed values over the same data. If any of these 569 conditions is not met, then the TLS session must be closed 570 immediately after sending a fatal evidence_failure(TBD) alert. 572 party1_certificate 573 Contains the X.509 certificate of the sender of the 574 evidence_end1 alert. If this certificate cannot be validated, 575 then TLS session must be closed immediately after sending one 576 of the following fatal alerts: bad_certificate(42), 577 unsupported_certificate(43), certificate_revoked(44), or 578 certificate_expired(45). These alerts are described in Section 579 7.2.2 of [TLS1.1]. 581 party1_signature 582 Contains the digital signature computed by the sender of the 583 evidence_end1 alert. If this signature cannot be validated, 584 then TLS session must be closed immediately after sending a 585 fatal evidence_failure(TBD) alert. 587 party2_certificate 588 Contains the X.509 certificate of the sender of the 589 evidence_end2 alert. While this certificate was probably 590 exchanged and validated in the Handshake Protocol, inclusion 591 here make it clear which certificate was employed by the signer 592 when the evidence is validated in the future, possibly by a 593 third party. 595 Party2_signature 596 Contains the digital signature computed by the sender of the 597 evidence_end2 alert using the evidence creation algorithm suite 598 identified in evidence_suite. The hash value is computed as: 600 Hash(evidence) 602 5. IANA Considerations 604 This document defines one TLS extension: evidence_creation(TBD). 605 This extension type value is assigned from the TLS Extension Type 606 registry defined in [TLSEXT]. 608 This document defines five TLS alert descriptions: the 609 evidence_start1(TBD), evidence_start2(TBD), evidence_end1(TBD), 610 evidence_end2(TBD), and evidence_failure(TBD). These alert 611 descriptions are assigned from the TLS Alert registry defined in 612 [TLS1.1]. 614 This document defines one TLS ContentType: evidence(TBD). This 615 ContentType value is assigned from the TLS ContentType registry 616 defined in [TLS1.1]. 618 This document establishes a registry for TLS Evidence Protocol 619 EvidenceMsgType. The first two entries in the registry are 620 request(1) and response(2). All additional TLS Evidence Protocol 621 EvidenceMsgType values are assigned by Standards Action as described 622 in [IANA]. 624 This document establishes a registry for Evidence Create Algorithm 625 suite identifiers. Appendix A lists the initial values for this 626 registry. Evidence Create Algorithm suite identifier values with the 627 first byte in the range 0-191 (decimal) inclusive are assigned by 628 Standards Action as described in [IANA]. Values with the first byte 629 in the range 192-254 (decimal) are assigned by Specification Required 630 as described in [IANA]. Values with the first byte 255 (decimal) are 631 reserved for Private Use as described in [IANA]. 633 6. Security Considerations 635 This document describes an extension to the TLS protocol, and the 636 security considerations in [TLS1.1] and [TLSEXT] apply. 637 Additionally, temporal and storage security considerations are 638 discussed below. 640 6.1. Temporal Considerations 642 Generating evidence that covers Application Data values that do not 643 explicitly or implicitly indicate the point in time at which the 644 Application Data was transferred over the TLS session might give rise 645 to replay attacks, post-dating, pre-dating, or other temporal 646 disputes. To avoid these concerns, the evidence includes an 647 indication of the date and time. The TLS implementation MUST NOT 648 attempt to extract date and time values from the Application Data; 649 doing so is likely to be error prone. Instead, the date and time 650 SHOULD come from a local clock or a trustworthy time server. Date 651 and time are provided by one of the parties, and the other party 652 determines that the date and time value is sufficiently accurate. 654 When a more highly trusted time source is needed, the Time-Stamp 655 Protocol [TSP] can be used to obtain a time-stamp on the evidence 656 from a trusted third party. 658 6.2. Storage Considerations 660 Parties that choose to preserve a plaintext record of Application 661 Data or Handshake Protocol messages for evidence verification at a 662 later time must ensure must ensure that this data is not 663 inappropriately disclosed by employing suitable physical protection 664 or cryptographic mechanisms that are at least as strong as the 665 selected TLS ciphersuite. 667 Suitable physical controls for the protection of Application Data or 668 Handshake Protocol messages containing keying material or sensitive 669 data should use removable storage media in conjunction with durable, 670 locking storage containers. If the removable media is transferred 671 from one location to another or backup copies are made, secure 672 handling protections ought to be employed, which might include the 673 use of insured or bonded couriers. 675 A suitable cryptographic mechanism provides confidentiality 676 protection, since the hash value in the evidence itself provides 677 integrity protection. One reasonable solution is to encrypt the 678 Handshake Protocol messages and Application Data messages with a 679 fresh symmetric encryption key using the same algorithm that was 680 negotiated for the selected TLS ciphersuite. The key generation 681 should follow the recommendations in [RANDOM]. Then, the symmetric 682 key is encrypted for storage with the party's RSA public key or long- 683 lived key-encryption key. The Cryptographic Message Syntax (CMS) 684 [CMS] offers a convenient way to keep all of this information 685 together. 687 An alternative cryptographic mechanism is to save the TLS session 688 itself. The negotiated TLS ciphersuite was already used to protect 689 the Application Data messages, and the Handshake Protocol messages 690 contain the keying material necessary to decrypt them if the party 691 retains the private keys and/or pre-shared secrets. 693 7. References 695 7.1. Normative References 697 [IANA] Narten, T., and H. Alvestrand, "Guidelines for Writing 698 an IANA Considerations Section in RFCs", RFC 3434, 699 October 1998. 701 [DSS] Federal Information Processing Standards Publication 702 (FIPS PUB) 186, Digital Signature Standard, 2000. 704 [PKCS1] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", 705 RFC 2313, March 1998. 707 [PKIX1] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 708 Public Key Infrastructure - Certificate and 709 Certificate Revocation List (CRL) Profile", RFC 3280, 710 April 2002. 712 [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0", 713 RFC 2246, January 1999. 715 [TLS1.1] Dierks, T., and E. Rescorla, "The Transport Layer Security 716 (TLS) Protocol, Version 1.1", RFC 4346, April 2006. 718 [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 719 and T. Wright, "Transport Layer Security (TLS) Extensions", 720 RFC 4366, April 2006. 722 [SHA] Federal Information Processing Standards Publication 723 (FIPS PUB) 180-2, Secure Hash Algorithm, 2002. 725 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 726 Requirement Levels", BCP 14, RFC 2119, March 1997. 728 [X9.62] X9.62-1998, "Public Key Cryptography For The Financial 729 Services Industry: The Elliptic Curve Digital 730 Signature Algorithm (ECDSA)", January 7, 1999. 732 7.2. Informative References 734 [AUTHZ] Brown, M., and R. Housley, "Transport Layer Security 735 (TLS) Authorization Extensions", work in progress, 736 draft-housley-tls-authz-extns. 738 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 739 RFC 3852, July 2004. 741 [TSP] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 742 "Internet X.509 Public Key Infrastructure: Time-Stamp 743 Protocol (TSP)", RFC 3161,August 2001. 745 8. Acknowledgements 747 Thanks to C. Robert Beattie, J.D. and Randy V. Sabett, J.D., CISSP 748 for their observations and comparisons between the Uniform Electronic 749 Transactions Act (1999) prepared by the National Conference of 750 Commissioners on Uniform State Laws versus the American Bar 751 Association's Digital Signature Guidelines (1996), their observations 752 regarding the strengths and weaknesses of these two approaches, and 753 their desire to promote trust and reduce potential for litigation in 754 online transactions. Their pro bono contribution of time and 755 expertise deserves recognition. 757 Appendix A. Evidence Create Algorithms 759 The following values define the EvidenceCreateSuite identifiers used 760 in the TLS Evidence Extensions. 762 An EvidenceCreateSuite defines a cipher specification supported by 763 TLS Evidence Extensions. A suite identifier names a public key 764 signature algorithm and an associated one-way hash function. A 765 registration is named as follows: 767 _WITH_ 769 These components have the following meaning: 771 772 Specifies the digital signature algorithm and key length 773 associated with the algorithm. It is used to digitally sign 774 the evidence. The "RSA_1024" value indicates the use of the 775 PKCS#1 v1.5 [PKCS1] digital signature algorithm using a 776 1024-bit public key. The "DSS_1024" value indicates the use of 777 the DSS digital signature algorithm [DSS] with a 1024-bit 778 public key. The "ECDSA_P384" value indicates the use of the 779 ECDSA digital signature algorithm [X9.62] using the P-384 named 780 elliptic curve. 782 783 Specifies the one-way hash function used as part of the digital 784 signature. The "SHA_1", "SHA_224", "SHA_256", "SHA_384", and 785 "SHA_512" values identify members of the Secure Hash Algorithm 786 family of one-way- hash functions [SHA]. 788 In most cases it will be appropriate to use the same algorithms and 789 certified public keys that were negotiated in the TLS Handshake 790 Protocol. The following additional steps are required in order to 791 employ the digital signature aspects of a TLS CipherSuite to a valid 792 EvidenceCreateSuite: 794 1) CipherSuites that do not include signature-capable certificates 795 cannot be used as EvidenceCreateSuite. 797 2) CipherSuites that specify the use of MD5 one-way hash function 798 should not be used as EvidenceCreateSuite. 800 Of course, any aspect of a CipherSuite that deals with symmetric 801 ciphers and symmetric cipher key lengths is not relevant to the 802 EvidenceCreateSuite. 804 All public key certificate profiles used in TLS are defined by the 805 IETF PKIX working group in [PKIX1]. When a key usage extension is 806 present, then either the digitalSignature bit or the nonRepudiation 807 bit MUST be set for the public key to be eligible for signing 808 evidence. If both bits are set, then this requirement is satisfied. 810 The following EvidenceCreateSuite definitions are made at this time. 811 Section 5 specifies the procedures for registering additional 812 EvidenceCreateSuite definitions. 814 EvidenceCreateSuite RSA_1024_WITH_SHA_1 = { 0x00, 0x01 }; 815 EvidenceCreateSuite RSA_1024_WITH_SHA_224 = { 0x00, 0x02 }; 816 EvidenceCreateSuite RSA_1024_WITH_SHA_256 = { 0x00, 0x03 }; 817 EvidenceCreateSuite RSA_2048_WITH_SHA_256 = { 0x00, 0x04 }; 819 EvidenceCreateSuite DSS_1024_WITH_SHA_1 = { 0x00, 0x11 }; 820 EvidenceCreateSuite DSS_2048_WITH_SHA_256 = { 0x00, 0x12 }; 822 EvidenceCreateSuite ECDSA_P256_WITH_SHA_256 = { 0x00, 0x21 }; 823 EvidenceCreateSuite ECDSA_P384_WITH_SHA_384 = { 0x00, 0x22 }; 824 EvidenceCreateSuite ECDSA_P521_WITH_SHA_512 = { 0x00, 0x23 }; 826 Author's Address 828 Mark Brown 829 RedPhone Security 830 2019 Palace Avenue 831 Saint Paul, MN 55105 832 USA 833 mark redphonesecurity com 835 Russell Housley 836 Vigil Security, LLC 837 918 Spring Knoll Drive 838 Herndon, VA 20170 839 USA 840 housley vigilsec com 842 Full Copyright Statement 844 Copyright (C) The Internet Society (2006). This document is subject 845 to the rights, licenses and restrictions contained in BCP 78, and 846 except as set forth therein, the authors retain all their rights. 848 This document and translations of it may be copied and furnished to 849 others, and derivative works that comment on or otherwise explain it 850 or assist in its implementation may be prepared, copied, published 851 and distributed, in whole or in part, without restriction of any 852 kind, provided that the above copyright notice and this paragraph are 853 included on all such copies and derivative works. However, this 855 document itself may not be modified in any way, such as by removing 856 the copyright notice or references to the Internet Society or other 857 Internet organizations, except as needed for the purpose of 858 developing Internet standards in which case the procedures for 859 copyrights defined in the Internet Standards process must be 860 followed, or as required to translate it into languages other than 861 English. 863 This document and the information contained herein are provided on an 864 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 865 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 866 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 867 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 868 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 869 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.