<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
          <!ENTITY bibxml2rfc-informative SYSTEM "draft-rescorla-tls-extended-random.xml-informative">
          <!ENTITY bibxml2rfc-normative SYSTEM "draft-rescorla-tls-extended-random.xml-normative">
]>

<!-- $Id -->
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc inline="yes"?>
<?rfc toc="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace='yes' ?>
<rfc category="info" docName="draft-rescorla-tls-extended-random-02.txt"
     ipr="pre5378Trust200902">

<front>
     <title abbrev="Extended TLS Random">Extended Random Values for TLS</title>

           <author initials="E.K." surname="Rescorla"
                   fullname="Eric Rescorla">
               <organization>RTFM, Inc.</organization>

               <address>
                   <postal>
                       <street>2064 Edgewood Drive</street>
                       <city>Palo Alto</city> 
                       <code>94303</code>
		       <region>CA</region>
                       <country>USA</country>
                   </postal>

                   <email>ekr@rtfm.com</email>
               </address>

           </author>

           <author initials="M." surname="Salter"
                   fullname="Margaret Salter">
               <organization>National Security Agency</organization>

               <address>
                   <postal>
                       <street>9800 Savage Rd.</street>
                       <city>Fort Meade</city> 
                       <code>20755-6709</code>
		       <state>MD</state>
                       <country>USA</country>
                   </postal>

                   <email>msalter@restarea.ncsc.mil</email>
               </address>
           </author>

           <date month="March" day="02" year="2009" />

           <abstract>
               <t>This document describes an extension for using
larger client and server Random values with
Transport Layer Security (TLS) and Datagram TLS (DTLS).
</t>
           </abstract>
       </front>
<middle>
<section title="Introduction" anchor="intro">
<t>
TLS <xref target="I-D.ietf-tls-rfc4346-bis" norm="true"/> and DTLS <xref target="RFC4347"/> use
a 32-byte "Random" value consisting
of a 32-bit time value time and 28 randomly generated bytes:
</t>
<artwork>
      struct {
         uint32 gmt_unix_time;
         opaque random_bytes[28];
      } Random;
</artwork>
<t>
The client and server each contribute a Random value which is then
mixed with secret keying material to produce the final per-association
keying material.
</t>
<t>
The United States Department of Defense has requested a TLS mode which
allows the use of longer public randomness values for use with 
high security level cipher suites like those specified in Suite B
<xref target="I-D.rescorla-tls-suiteb"/>. The rationale for this as
stated by DoD is that the public randomness for each side should
be at least twice as long as the security level for cryptographic
parity, which makes the 224 bits of randomness provided by the
current TLS random values insufficient.
</t>
<t>
This document specifies
an extension which allows for additional randomness to be exchanged
in the Hello messages.
</t>
</section>
<section title="Conventions Used In This Document">
  <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 title="The ExtendedRandom Extension" anchor="extension.def">
<t>
This document defines a new TLS extension called "extended_random".
</t>
<t>
The "extended_random" extension carried in a new TLS extension called "ExtendedRandom".
</t>
<artwork><![CDATA[
     struct {
         opaque extended_random_value<0..2^16-1>;
     } ExtendedRandom;
]]></artwork>
<t>
The extended_random_value MUST be a randomly generated byte string.
A cryptographically secure PRNG <xref target="RFC4086" norm="true"/> SHOULD
be used.
</t>
<section title="Negotiating the ExtendedRandom Extension">
<t>
The client requests support for the extended randomness feature by 
sending an "extended_random" extension in its ClientHello. The
"extension_data" field contains an ExtendedRandom value.
</t>
<t>
When a server which does not recognize the "extended_random"
extension receives one, it will ignore it as required.
A server which recognizes the
extension MAY choose to ignore it, in which case it SHOULD
continue with the exchange as if it had not received
the extension.
</t>
<t>
If the server wishes to use the extended randomness feature, it
MUST send its own "extended_random" extension with an 
extended_random_value equal in length to the client's
extended_random_value. Clients SHOULD check the length of the
server's extended_random_value and generate a fatal "illegal_parameter"
error if it is present but does does not match the
length that was transmitted in the ClientHello.
</t>
<t>
Because TLS does not permit servers to request extensions which
the client did not offer, the client may not offer the
"extended_random" extension even if the server requires it.
In this case, the server should generate a fatal
"handshake_failure" alert.
</t>
<t>
Because there is no way to mark extensions as critical, 
the server may ignore the "extended_random" extension even
though the client requires it. If a client requires the
extended randomness input feature but the server does not negotiate it,
the client SHOULD generate a fatal "handshake_failure" alert.
</t>
</section>
<section title="PRF Modifications">
<t>
When the extended randomness feature is in use, the extended
random values MUST be mixed into the PRF along with the client and
server random values during the PMS->MS conversion. Thus,
the PRF becomes:
</t>
<artwork>
       master_secret = PRF(pre_master_secret, "master secret",
                           ClientHello.random + 
                           ClientHello.extended_random_value +
                           ServerHello.random +
                           ServerHello.extended_random_value)[0..47];
</artwork>
<t>
Because new extensions may not be introduced in resumed handshakes,
mixing in the extended inputs during the MS->keying material
conversion would simply involve mixing in the same material twice.
Therefore, the extended random inputs are only used when the PMS is
converted into the MS. 
</t>
</section>
</section>
<section title="Security Considerations">
<section title="Threats to TLS">
<t>
When this extension is in use it increases the amount of data that 
an attacker can inject into the PRF. This potentially would allow
an attacker who had partially compromised the PRF greater scope
for influencing the output. Hash-based PRFs like the one in
TLS are designed to be fairly indifferent to the input size
(the input is already 
greater than the block size of most hash functions), however
there is currently no proof that a larger input space
would not make attacks easier.
</t>
<t>
Another concern is that bad implementations might generate low
entropy extented random values. TLS is designed
to function correctly even when fed low-entropy random values
because they are primarily used to generate distinct keying
material for each connection. 
</t>
</section>
</section>
<section title="IANA Considerations">
      <t>This document defines an extension to TLS, in accordance with <xref
      target="I-D.ietf-tls-rfc4366-bis"></xref>:</t>

      <figure>
        <artwork><![CDATA[
  enum { extended_random (??) } ExtensionType;
]]></artwork>
      </figure>

      <t>[[ NOTE: These values need to be assigned by IANA ]]</t>
</section>
<section title="Acknowledgements">
<t>
This work was supported by the US Department of Defense.
</t>
</section>
</middle>
<back>
<references title="Normative References">
           &bibxml2rfc-normative;
</references>
<references title="Informative References">
           &bibxml2rfc-informative;
</references>
</back>
</rfc>
