<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.28 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc docmapping="yes"?>

<rfc ipr="trust200902" docName="draft-thomson-saag-context-labels-00" category="std">

  <front>
    <title abbrev="Context Labels">Using Context Labels for Domain Separation of Cryptographic Objects</title>

    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Mozilla</organization>
      <address>
        <email>martin.thomson@gmail.com</email>
      </address>
    </author>
    <author initials="D." surname="Gillmor" fullname="Daniel Kahn Gillmor">
      <organization>ACLU</organization>
      <address>
        <email>dkg@fifthhorseman.net</email>
      </address>
    </author>
    <author initials="B." surname="Kaduk" fullname="Benjamin Kaduk">
      <organization>Unaffiliated</organization>
      <address>
        <email>kaduk@mit.edu</email>
      </address>
    </author>

    <date year="2016"/>

    
    
    

    <abstract>


<t>A single cryptographic key is sometimes relied upon to produce muliple
cryptographic artifacts that each have different semantics.  This produces a
potential problem whereby artifacts with different intended uses can be
confused.  The addition of context labels removes this problem.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The same cryptographic primitive can be used in a range of different contexts.
These uses are often developed in isolation, which leads to the potential for
data structures that are used in one protocol having plausible interpretations
in other protocols.  This gives an opportunity for cross-protocol attacks,
wherein a well-behaved participant in one protocol can be coerced into creating
a cryptographic object that, when interpreted by a different protocol,
introduces a vulnerability.</t>

<t>Reuse of the same key in multiple contexts is strongly discouraged.  However, in
some cases, use of the same key might be unavoidable.  For example, the same key
might need to be used in multiple versions of the same protocol, or a protocol
might define multiple uses for a particular type of key.</t>

<t>Including a unique protocol- and usage- specific context label as input to a
cryptographic operation prevents objects created in one context from being
mistakenly used in a different context.</t>

<t>This document describes a uniform approach for the inclusion of context labels
and a registry for unique labels.  It covers the use of these labels in digital
signatures, key derivation functions (KDFs), and message authentication codes
(MACs).</t>

<t>Existing protocols might already include a unique context label.  This document
collects some of these existing labels into the context label registry.</t>

<section anchor="notational-conventions" title="Notational Conventions">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be
interpreted as described in <xref target="RFC2119"></xref>.</t>

</section>
</section>
<section anchor="existing-functions-with-context-labels" title="Existing Functions with Context Labels">

<t>The following cryptographic primitives define an explicit argument for
identifying a context:</t>

<t><list style="symbols">
  <t>Ed448 and Ed448ph <xref target="I-D.irtf-cfrg-eddsa"></xref> define a <spanx style="verb">context</spanx> argument.</t>
  <t>HKDF <xref target="RFC5869"></xref> specifies an <spanx style="verb">info</spanx> argument to the HKDF-Expand function.</t>
</list></t>

</section>
<section anchor="context" title="Generic Signature or MAC Function with Context">

<t>Many pre-existing signature and MAC schemes do not define an explicit context
label.  This document defines a new signature function that adds a context label
to an existing function.</t>

<t>Given a signature function S that takes a key K and message M as a sequence of
octets, a signature with context function Sc is defined.  The signature with
context function Sc takes three arguments, K, M, and a context label C as a
sequence of octets and is defined as:</t>

<figure><artwork type="inline"><![CDATA[
   Sc(K, M, C) = S(K, C || M)
]]></artwork></figure>

<t>That is, the signature is changed to accept a message that is the concatenation
of the context label and the message.</t>

<t>This scheme MUST be used with:</t>

<t><list style="symbols">
  <t>RSA (both PKCS#1 and PSS) <xref target="RFC3447"></xref></t>
  <t>ECDSA <xref target="X9.62"></xref></t>
  <t>HMAC <xref target="RFC2104"></xref></t>
  <t>Ed25519 and Ed25519ph <xref target="I-D.irtf-cfrg-eddsa"></xref></t>
</list></t>

</section>
<section anchor="rec" title="Recommendations for Context Labels">

<t>In order to avoid attacks that permit use of a cryptographic object for purposes
other than intended, a context label C MUST NOT be a prefix of any other
context label.</t>

<t>New specifications defining context labels SHOULD select context labels that end
with a single zero-valued octet and do not contain any other zero-valued octets.
Context labels SHOULD be at least 12 octets in length.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This document establishes a “Cryptographic Context Label” registry.</t>

<t>Entries in this registry contain the following fields:</t>

<t><list style="hanging">
  <t hangText='Context Label:'>
  A sequence of octets between 1 and 255 octets in length, displayed as a
hexadecimal string</t>
  <t hangText='String:'>
  An optional, informative ASCII representation of the context label</t>
  <t hangText='Specification:'>
  A reference to a specification describing the use of the context label</t>
</list></t>

<t>Context labels in this registry MUST NOT be a prefix of any other context label
in the registry.  For example, if 0x01ab00 is registered, then a registration for
0x01 or 0x01ab007c MUST be rejected.</t>

<t>A context label that is 12 octets or more in length and contains exactly one
zero-valued octet at the end can be registered on a First-Come, First-Served
basis <xref target="RFC5226"></xref>.  Context labels that do not meet these requirements require
Expert Review <xref target="RFC5226"></xref>.</t>

<t>The initial contents of this registry are included in <xref target="ok"/>.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>In general, it is best to limit any cryptographic material to being used for a
single purpose.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor='RFC2104' target='http://www.rfc-editor.org/info/rfc2104'>
<front>
<title>HMAC: Keyed-Hashing for Message Authentication</title>
<author initials='H.' surname='Krawczyk' fullname='H. Krawczyk'><organization /></author>
<author initials='M.' surname='Bellare' fullname='M. Bellare'><organization /></author>
<author initials='R.' surname='Canetti' fullname='R. Canetti'><organization /></author>
<date year='1997' month='February' />
<abstract><t>This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key.  The cryptographic strength of HMAC depends on the properties of the underlying hash function.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind</t></abstract>
</front>
<seriesInfo name='RFC' value='2104'/>
<seriesInfo name='DOI' value='10.17487/RFC2104'/>
</reference>



<reference  anchor='RFC3447' target='http://www.rfc-editor.org/info/rfc3447'>
<front>
<title>Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1</title>
<author initials='J.' surname='Jonsson' fullname='J. Jonsson'><organization /></author>
<author initials='B.' surname='Kaliski' fullname='B. Kaliski'><organization /></author>
<date year='2003' month='February' />
<abstract><t>This memo represents a republication of PKCS #1 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process.  The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='3447'/>
<seriesInfo name='DOI' value='10.17487/RFC3447'/>
</reference>



<reference  anchor='RFC5226' target='http://www.rfc-editor.org/info/rfc5226'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials='T.' surname='Narten' fullname='T. Narten'><organization /></author>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'><organization /></author>
<date year='2008' month='May' />
<abstract><t>Many protocols make use of identifiers consisting of constants and other well-known values.  Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec).  To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority.  For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t>In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made.  If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role.  This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t>This document obsoletes RFC 2434.  This document specifies an Internet Best  Current Practices for the Internet Community, and requests discussion and  suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='26'/>
<seriesInfo name='RFC' value='5226'/>
<seriesInfo name='DOI' value='10.17487/RFC5226'/>
</reference>



<reference  anchor='RFC5869' target='http://www.rfc-editor.org/info/rfc5869'>
<front>
<title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title>
<author initials='H.' surname='Krawczyk' fullname='H. Krawczyk'><organization /></author>
<author initials='P.' surname='Eronen' fullname='P. Eronen'><organization /></author>
<date year='2010' month='May' />
<abstract><t>This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications.  The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions.  This document is not an Internet  Standards Track specification; it is published for informational  purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='5869'/>
<seriesInfo name='DOI' value='10.17487/RFC5869'/>
</reference>



<reference anchor='I-D.irtf-cfrg-eddsa'>
<front>
<title>Edwards-curve Digital Signature Algorithm (EdDSA)</title>

<author initials='S' surname='Josefsson' fullname='Simon Josefsson'>
    <organization />
</author>

<author initials='I' surname='Liusvaara' fullname='Ilari Liusvaara'>
    <organization />
</author>

<date month='March' day='21' year='2016' />

<abstract><t>The elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA) is described.  The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-irtf-cfrg-eddsa-05' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-irtf-cfrg-eddsa-05.txt' />
</reference>


<reference anchor="X9.62" >
  <front>
    <title>Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Sig nature Algorithm (ECDSA)</title>
    <author >
      <organization>ANSI</organization>
    </author>
    <date year="1998"/>
  </front>
  <seriesInfo name="ANSI X9.62" value=""/>
</reference>


    </references>

    <references title='Informative References'>





<reference  anchor='RFC5246' target='http://www.rfc-editor.org/info/rfc5246'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'><organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2008' month='August' />
<abstract><t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5246'/>
<seriesInfo name='DOI' value='10.17487/RFC5246'/>
</reference>



<reference anchor='I-D.ietf-tls-tls13'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<date month='March' day='22' year='2016' />

<abstract><t>This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol.  The TLS protocol allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-tls13-12' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-12.txt' />
</reference>




    </references>


<section anchor="ok" title="Existing Protocols with Context Labels">

<texttable>
      <ttcol align='left'>Context label</ttcol>
      <ttcol align='left'>String</ttcol>
      <ttcol align='left'>Specification</ttcol>
      <c>20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 54 4c 53 20 31 2e 33 2c 20 73 65 72 76 65 72 20 43 65 72 74 69 66 69 63 61 74 65 56 65 72 69 66 79 00</c>
      <c>(64 spaces)TLS 1.3, server CertificateVerify\0</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 54 4c 53 20 31 2e 33 2c 20 63 6c 69 65 6e 74 20 43 65 72 74 69 66 69 63 61 74 65 56 65 72 69 66 79 00</c>
      <c>(64 spaces)TLS 1.3, client CertificateVerify\0</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>54 4c 53 20 31 2e 33 2c 20 65 78 70 61 6e 64 65 64 20 73 74 61 74 69 63 20 73 65 63 72 65 74</c>
      <c>TLS 1.3, expanded static secret</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>54 4c 53 20 31 2e 33 2c 20 65 78 70 61 6e 64 65 64 20 65 70 68 65 6d 65 72 61 6c 20 73 65 63 72 65 74</c>
      <c>TLS 1.3, expanded ephemeral secret</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>54 4c 53 20 31 2e 33 2c 20 74 72 61 66 66 69 63 20 73 65 63 72 65 74</c>
      <c>TLS 1.3, traffic secret</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>54 4c 53 20 31 2e 33 2c 20 72 65 73 75 6d 70 74 69 6f 6e 20 6d 61 73 74 65 72 20 73 65 63 72 65 74</c>
      <c>TLS 1.3, resumption master secret</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>54 4c 53 20 31 2e 33 2c 20 65 78 70 6f 72 74 65 72 20 6d 61 73 74 65 72 20 73 65 63 72 65 74</c>
      <c>TLS 1.3, exporter master secret</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>54 4c 53 20 31 2e 33 2c 20 65 61 72 6c 79 20 68 61 6e 64 73 68 61 6b 65 20 6b 65 79 20 65 78 70 61 6e 73 69 6f 6e 2c 20 63 6c 69 65 6e 74 20 77 72 69 74 65 20 6b 65 79</c>
      <c>TLS 1.3, early handshake key expansion, client write key</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>54 4c 53 20 31 2e 33 2c 20 65 61 72 6c 79 20 68 61 6e 64 73 68 61 6b 65 20 6b 65 79 20 65 78 70 61 6e 73 69 6f 6e 2c 20 73 65 72 76 65 72 20 77 72 69 74 65 20 6b 65 79</c>
      <c>TLS 1.3, early handshake key expansion, server write key</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>54 4c 53 20 31 2e 33 2c 20 65 61 72 6c 79 20 68 61 6e 64 73 68 61 6b 65 20 6b 65 79 20 65 78 70 61 6e 73 69 6f 6e 2c 20 63 6c 69 65 6e 74 20 77 72 69 74 65 20 69 76</c>
      <c>TLS 1.3, early handshake key expansion, client write iv</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>54 4c 53 20 31 2e 33 2c 20 65 61 72 6c 79 20 68 61 6e 64 73 68 61 6b 65 20 6b 65 79 20 65 78 70 61 6e 73 69 6f 6e 2c 20 73 65 72 76 65 72 20 77 72 69 74 65 20 69 76</c>
      <c>TLS 1.3, early handshake key expansion, server write iv</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>54 4c 53 20 31 2e 33 2c 20 65 61 72 6c 79 20 61 70 70 6c 69 63 61 74 69 6f 6e 20 64 61 74 61 20 6b 65 79 20 65 78 70 61 6e 73 69 6f 6e 2c 20 63 6c 69 65 6e 74 20 77 72 69 74 65 20 6b 65 79</c>
      <c>TLS 1.3, early application data key expansion, client write key</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>54 4c 53 20 31 2e 33 2c 20 65 61 72 6c 79 20 61 70 70 6c 69 63 61 74 69 6f 6e 20 64 61 74 61 20 6b 65 79 20 65 78 70 61 6e 73 69 6f 6e 2c 20 73 65 72 76 65 72 20 77 72 69 74 65 20 6b 65 79</c>
      <c>TLS 1.3, early application data key expansion, server write key</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>54 4c 53 20 31 2e 33 2c 20 65 61 72 6c 79 20 61 70 70 6c 69 63 61 74 69 6f 6e 20 64 61 74 61 20 6b 65 79 20 65 78 70 61 6e 73 69 6f 6e 2c 20 63 6c 69 65 6e 74 20 77 72 69 74 65 20 69 76</c>
      <c>TLS 1.3, early application data key expansion, client write iv</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>54 4c 53 20 31 2e 33 2c 20 65 61 72 6c 79 20 61 70 70 6c 69 63 61 74 69 6f 6e 20 64 61 74 61 20 6b 65 79 20 65 78 70 61 6e 73 69 6f 6e 2c 20 73 65 72 76 65 72 20 77 72 69 74 65 20 69 76</c>
      <c>TLS 1.3, early application data key expansion, server write iv</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>54 4c 53 20 31 2e 33 2c 20 68 61 6e 64 73 68 61 6b 65 20 6b 65 79 20 65 78 70 61 6e 73 69 6f 6e 2c 20 63 6c 69 65 6e 74 20 77 72 69 74 65 20 6b 65 79</c>
      <c>TLS 1.3, handshake key expansion, client write key</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>54 4c 53 20 31 2e 33 2c 20 68 61 6e 64 73 68 61 6b 65 20 6b 65 79 20 65 78 70 61 6e 73 69 6f 6e 2c 20 73 65 72 76 65 72 20 77 72 69 74 65 20 6b 65 79</c>
      <c>TLS 1.3, handshake key expansion, server write key</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>54 4c 53 20 31 2e 33 2c 20 68 61 6e 64 73 68 61 6b 65 20 6b 65 79 20 65 78 70 61 6e 73 69 6f 6e 2c 20 63 6c 69 65 6e 74 20 77 72 69 74 65 20 69 76</c>
      <c>TLS 1.3, handshake key expansion, client write iv</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>54 4c 53 20 31 2e 33 2c 20 68 61 6e 64 73 68 61 6b 65 20 6b 65 79 20 65 78 70 61 6e 73 69 6f 6e 2c 20 73 65 72 76 65 72 20 77 72 69 74 65 20 69 76</c>
      <c>TLS 1.3, handshake key expansion, server write iv</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>54 4c 53 20 31 2e 33 2c 20 61 70 70 6c 69 63 61 74 69 6f 6e 20 64 61 74 61 20 6b 65 79 20 65 78 70 61 6e 73 69 6f 6e 2c 20 63 6c 69 65 6e 74 20 77 72 69 74 65 20 6b 65 79</c>
      <c>TLS 1.3, application data key expansion, client write key</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>54 4c 53 20 31 2e 33 2c 20 61 70 70 6c 69 63 61 74 69 6f 6e 20 64 61 74 61 20 6b 65 79 20 65 78 70 61 6e 73 69 6f 6e 2c 20 73 65 72 76 65 72 20 77 72 69 74 65 20 6b 65 79</c>
      <c>TLS 1.3, application data key expansion, server write key</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>54 4c 53 20 31 2e 33 2c 20 61 70 70 6c 69 63 61 74 69 6f 6e 20 64 61 74 61 20 6b 65 79 20 65 78 70 61 6e 73 69 6f 6e 2c 20 63 6c 69 65 6e 74 20 77 72 69 74 65 20 69 76</c>
      <c>TLS 1.3, application data key expansion, client write iv</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
      <c>54 4c 53 20 31 2e 33 2c 20 61 70 70 6c 69 63 61 74 69 6f 6e 20 64 61 74 61 20 6b 65 79 20 65 78 70 61 6e 73 69 6f 6e 2c 20 73 65 72 76 65 72 20 77 72 69 74 65 20 69 76</c>
      <c>TLS 1.3, application data key expansion, server write iv</c>
      <c><xref target="I-D.ietf-tls-tls13"></xref></c>
</texttable>

<t>Note that in the above table, the following categories of entry do not conform
with the guidance in <xref target="rec"/>:</t>

<t><list style="symbols">
  <t>Labels for the TLS 1.3 HKDF input</t>
</list></t>

</section>
<section anchor="bad" title="Existing Protocols without Context Labels">

<t>TLS versions 1.2 <xref target="RFC5246"></xref> and earlier do not use context labels for signatures
though the use of the pseudorandom function (PRF) uses version-agnostic labels.</t>

</section>
<section anchor="acknowledgments" title="Acknowledgments">

<t>This document originated from hallway discussions at IETF 95; thank
you to those who helped spark the idea.</t>

</section>


  </back>
</rfc>

