idnits 2.17.1 draft-farrell-tls-pemesni-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (19 November 2021) is 886 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-13 == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-svcb-https-08 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS S. Farrell 3 Internet-Draft Trinity College Dublin 4 Intended status: Experimental 19 November 2021 5 Expires: 23 May 2022 7 PEM file format for ECH 8 draft-farrell-tls-pemesni-02 10 Abstract 12 Encrypted ClientHello (ECH) key pairs need to be configured into TLS 13 servers, some of which can be built with different TLS libraries, so 14 there is a benefit and little cost in documenting a file format to 15 use for these, similar to how RFC7468 defines other PEM file formats. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 23 May 2022. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Revised BSD License text as 45 described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Revised BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3. ECHConfig file . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 54 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 56 7. Normative References . . . . . . . . . . . . . . . . . . . . 3 57 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 4 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1. Introduction 62 Encrypted ClientHello (ECH) [I-D.ietf-tls-esni] for TLS1.3 [RFC8446] 63 defines a confidentiality mechanism for server names and other 64 ClientHello content in TLS. That requires publication of an 65 ECHConfigList data structure in an HTTPS or SVCB RR 66 [I-D.ietf-dnsop-svcb-https] in the DNS. An ECHConfigList can contain 67 one or more ECHConfig values. An ECHConfig structure contains the 68 public component of a key pair that will typically be periodically 69 (re-)generated by some key manager for a TLS server. TLS servers 70 then need to be configured to use these key pairs, and given that 71 various TLS servers can be built with different TLS libraries, there 72 is a benefit in having a standard format for ECH key pairs, just as 73 was done with [RFC7468]. 75 [[This idea could: a) wither on the vine, b) be published as it's own 76 RFC, or c) end up as a PR for [I-D.ietf-tls-esni]. There is no 77 absolute need for this to be in the RFC that defines ECHO, so (b) 78 seems feasible if there's enough interest, hence this draft. The 79 source for this is in https://github.com/sftcd/pemesni/ PRs are 80 welcome there too.]] 82 2. Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 86 "OPTIONAL" in this document are to be interpreted as described in BCP 87 14 [RFC2119] [RFC8174] when, and only when, they appear in all 88 capitals, as shown here. 90 3. ECHConfig file 92 The public and private keys MUST both be PEM encoded. The file 93 contains the catenation of the PEM encoding of the private key 94 followed by the PEM encoding of the public key as an ECHConfigList 95 containing exactly one ECHConfig. The private key MUST be encoded as 96 a PKCS#8 PrivateKey. The public key MUST be the base64 encoded form 97 of an ECHConfigList value that can also be published in the DNS. The 98 string "ECHCONFIG" MUST be used in the PEM file delimiter for the 99 public key. 101 There MUST only be one key pair in each file even if a server 102 publishes multiple public keys in the DNS in one ECHConfigList 103 structure. 105 Figure 1 shows an example ECHConfig PEM File 107 -----BEGIN PRIVATE KEY----- 108 MC4CAQAwBQYDK2VuBCIEICjd4yGRdsoP9gU7YT7My8DHx1Tjme8GYDXrOMCi8v1V 109 -----END PRIVATE KEY----- 110 -----BEGIN ECHCONFIG----- 111 AD7+DQA65wAgACA8wVN2BtscOl3vQheUzHeIkVmKIiydUhDCliA4iyQRCwAEAAEA 112 AQALZXhhbXBsZS5jb20AAA== 113 -----END ECHCONFIG----- 115 Figure 1: Example ECHConfig PEM file 117 4. Security Considerations 119 Storing cryptographic keys in files leaves them vulnerable should 120 anyone get shell access to the TLS server machine. So: Don't let 121 that happen:-) 123 5. Acknowledgements 125 TBD, as needed 127 6. IANA Considerations 129 There are none so this section can be deleted later. 131 7. Normative References 133 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 134 Requirement Levels", BCP 14, RFC 2119, 135 DOI 10.17487/RFC2119, March 1997, 136 . 138 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 139 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 140 April 2015, . 142 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 143 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 144 May 2017, . 146 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 147 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 148 . 150 [I-D.ietf-tls-esni] 151 Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 152 Encrypted Client Hello", Work in Progress, Internet-Draft, 153 draft-ietf-tls-esni-13, 12 August 2021, 154 . 157 [I-D.ietf-dnsop-svcb-https] 158 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 159 and parameter specification via the DNS (DNS SVCB and 160 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 161 dnsop-svcb-https-08, 12 October 2021, 162 . 165 Appendix A. Changes 167 From -01 to -02: 169 * ECHO -> ECH 171 From -00 to -01: 173 * ESNI -> ECHO 175 Author's Address 177 Stephen Farrell 178 Trinity College Dublin 179 Dublin 180 2 181 Ireland 183 Phone: +353-1-896-2354 184 Email: stephen.farrell@cs.tcd.ie