<?xml version="1.0" encoding="US-ASCII"?>
<!-- this is version 5 of this xml2rfc template -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc7468 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.7468.xml">
<!ENTITY rfc8174 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY rfc8446 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.8446.xml">
<!ENTITY I-D.ietf-tls-esni SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tls-esni">
<!ENTITY I-D.ietf-dnsop-svcb-httpssvc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dnsop-svcb-httpssvc">

]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc category="exp" docName="draft-farrell-tls-pemesni-01" ipr="trust200902" >
  <front>
    <title abbrev="PEM file format for ECHO">PEM file format for ECHO</title>

    <author fullname="Stephen Farrell" initials="S." surname="Farrell">
      <organization>Trinity College Dublin</organization>

      <address>
        <postal>
          <street/>

          <city>Dublin</city>

          <region/>

          <code>2</code>

          <country>Ireland</country>
        </postal>

        <phone>+353-1-896-2354</phone>

        <email>stephen.farrell@cs.tcd.ie</email>
      </address>
    </author>

    <date year="2020"/>

    <area>Security Area</area>

    <workgroup>TLS</workgroup>

    <keyword>TLS</keyword>

    <keyword>ESNI</keyword>

    <abstract>
        <t>Encrypted ClientHello key pairs need to be configured into TLS servers, some of which
            can be built with different TLS libraries, so there is a benefit and
            little cost in documenting a file format to use for these, similar to
            how RFC7468 defines other PEM file formats.
            </t> 
    </abstract>
  </front>

  <middle>
    <section title="Introduction">

        <t>Encrypted ClientHello (ECHO)
            <xref target="I-D.ietf-tls-esni"/> for TLS1.3 <xref target="RFC8446"/>
            defines a confidentiality mechanism for server names and other ClientHello 
            content in TLS.
            That requires publication of an ECHOConfig data structure in an HTTPSSVC RR
            <xref target="I-D.ietf-dnsop-svcb-httpssvc"/> in the DNS.
            An ECHOConfig structure contains the public component of a key pair
            that will typically be periodically (re-)generated by some key manager
            for a TLS server.
            TLS servers then need to be configured to use these key pairs, 
            and given that various TLS servers can be built with different
            TLS libraries, there is a benefit in having a standard format for
            ECHO key pairs, just as was done with <xref target="RFC7468"/>. 
        </t>

        <t>[[This idea could: a) wither on the vine, b) be published
            as it's own RFC, or c) end up as a PR for <xref target="I-D.ietf-tls-esni"/>.
            There is no absolute need for this to be in the RFC that
            defines ECHO, so (b) seems feasible if there's enough
            interest, hence this draft.
            The source for this is in https://github.com/sftcd/pemesni/ 
            PRs are welcome there too.]]
        </t>

      </section>

      <section title="Terminology">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
        "OPTIONAL" in this document are to be interpreted as described in BCP
        14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.</t>
      </section>

      <section title="ECHOConfig file">

              <t>The public and private keys MUST both
                  be PEM encoded. The file contains the catenation of the PEM encoding
                  of the private key followed by the PEM encoding of the public key plus
                  additional data.
                  The private key MUST be encoded as a PKCS#8 PrivateKey. The public
                  key MUST be the base64 encoded form of the ECHOConfig value that 
                  is published in the DNS. The string "ECHOCONFIG" MUST be used in the PEM
                  file delimiter for the public key.</t>

              <t>There MUST only be one key pair in each file even if a server publishes
                  multiple public keys in one ECHOConfig structure.</t>

              <t><xref target="sample"/> shows an example ECHO PEM File</t>

            <figure anchor="sample" title="Example ESNI PEM file" >
            <artwork><![CDATA[
-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VuBCIEIGgpQxiNHuprxZUs0d1O7kgRyb/PqZC1sRqSBqeDQfZ0
-----END PRIVATE KEY-----
-----BEGIN ECHOCONFIG-----
/wMAC2V4YW1wbGUuY29tACQAHQAgKyaDNGHTg1uFhCZ2znaFcJNFdcG3if0ko1sP
UjxprWcAAgACEwEBBAAA
-----END ECHOCONFIG-----
            ]]></artwork>
            </figure>

      </section>



    <section title="Security Considerations">
        <t>Storing cryptographic keys in files leaves them vulnerable should
            anyone get shell access to the TLS server machine.
            So: Don't let that happen:-)</t>

    </section>

    <section title="Acknowledgements">
        <t>TBD, as needed</t>
    </section>

    <section title="IANA Considerations">
        <t>There are none so this section can be deleted later.</t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>
      <?rfc include='reference.RFC.7468'?>
      <?rfc include='reference.RFC.8174'?>
      <?rfc include='reference.RFC.8446'?>
      &I-D.ietf-tls-esni;
      &I-D.ietf-dnsop-svcb-httpssvc;

    </references>

    <!--
    <references title="Informative References">
    </references>

    <section title="Change Log ">
      <t>[[RFC editor: please remove this before publication.]]</t>

      <t>From -00 to -01:
          <list style="symbols">
              <t>Re-structured a bit after re-reading rfc8615</t>
          </list>
      </t>
    </section>
    -->

    <section title="Changes">

      <t>From -00 to -01:
          <list style="symbols">
            <t>ESNI -> ECHO</t>
          </list>
      </t>
    </section>

  </back>
</rfc>
