<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
]>




<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>

<rfc docName="draft-asmithee-tls-dnssec-downprot-00"
     ipr="trust200902" category="std" updates="10000">

<front>
  <title abbrev="TLS DNSSEC Chain Downgrade Protection">
    TLS Downgrade protection extension for TLS DNSSEC Authentication Chain Extension
  </title>
  <author fullname="Alan Smithee" surname="Alan Smithee">
    <address>
      <email>pwouters@redhat.com</email>
    </address>
  </author>
  <author fullname="Alan Smithee" surname="Alan Smithee">
    <address>
      <email>ietf-dane@dukhovni.org</email>
    </address>
  </author>

  <date year="2018" />
  <area>Security</area>
  <workgroup>TLS</workgroup>
  <abstract>
    <t>
      This draft specifies a TLS extension that adds downgrade
      protection for another TLS extension, <xref target="dnssec-chain-extension"/>.
      Without the downgrade protection specified in this TLS extension, the
      only effect of deploying <xref target="dnssec-chain-extension"/> is
      to reduce TLS security from the standard "WebPKI security" to
      "WebPKI or DANE, whichever is weaker".
    </t>

    <t>
      This draft dictates that <xref target="dnssec-chain-extension"/> MUST
      only be used in combination with this TLS extension, whose only content
      is a two octet SupportLifetime value. A value of 0 prohibits the TLS client
      from unilaterally requiring ongoing use of both TLS extensions based on prior
      observation of their use (pinning). A non-zero value is the value in hours
      for which this TLS extension as well as <xref target="dnssec-chain-extension"/>
      MUST appear in subsequent TLS handshakes to the same TLS hostname and port. If this TLS
      extention or <xref target="dnssec-chain-extension"/> is missing from the TLS
      handshake within this observed pinning time, the TLS client MUST assume it
      is under attack and abort the TLS connection.
    </t>
  </abstract>
</front>

<middle>
  <section title="Requirements Notation">
    <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="Introduction">
    <t>
      This draft specifies a TLS extension that adds downgrade
      protection for another TLS extension, <xref target="dnssec-chain-extension"/>.
      Without the downgrade protection specified in this TLS extension, the
      only effect of deploying <xref target="dnssec-chain-extension"/> is
      to reduce TLS security from the standard "WebPKI security" to
      "WebPKI or DANE, whichever is weaker".
    </t>

    <t>
      This draft dictates that <xref target="dnssec-chain-extension"/> MUST
      only be used in combination with this TLS extension, whose only content
      is a two byte SupportLifetime value. A value of 0 prohibits the TLS client
      from unilaterally requiring ongoing use of both TLS extensions based on prior
      observation of their use (pinning). A non-zero value is the value in hours
      for which this TLS extension as well as <xref target="dnssec-chain-extension"/>
      MUST appear in subsequent TLS handshakes to the same hostname and port. If this TLS
      extention or <xref target="dnssec-chain-extension"/> is missing from the TLS
      handshake within this observed pinning time, the TLS client MUST assume it
      is under attack and abort the TLS connection.
    </t>
    
  </section> <!-- introduction -->

  <section title="TLS DNSSEC Extension Downgrade Protection Extension format">

      <t>
    The "extension_data" field of the "dnssec_chain_commit" extension 
    contains a two octet value specifying the pinning time in hours for both
    this extension and <xref target="dnssec-chain-extension"/> in the following form:
      </t>

      <figure>
        <artwork>
    struct {
        uint16 SupportLifetime;
    } DnssecChainExtensionCommitTime;
        </artwork>
      </figure>

      <t>
      A zero "SupportLifetime" prohibits the client from unilaterally
      requiring ongoing use of this extension or <xref target="dnssec-chain-extension"/>
      based on prior observation of their use (pinning).
      </t>

      <t>
      A non-zero value signifies the time in hours for which this resource
      commits to publishing both this extension and <xref target="dnssec-chain-extension"/>.
      If within the specified time a TLS connection for this resource omits either TLS extension, the TLS client
      MUST conclude it is under attack and MUST abort the TLS connection.
      </t>

  </section>

  <section title="Operational Considerations">
  <t>A positive DANE validated response for the TLSA record in
   <xref target="dnssec-chain-extension"/> MUST override any previous
   SupportLifetime information that the TLS client stored previously.
   In addition, if the TLS client previously obtained a
   valid TLSA record with a SupportLifetime commitment further into the future, and as part
   of the current TLS handshake it receives a DNSSEC-validated answer containing no TLSA
   record and a Denial of Existence proof via <xref target="dnssec-chain-extension"/>,
   the TLS client MUST clear the previously stored TLS extensions pinning value.
  </t>
  <t>If a specific resource is served using multiple TLS servers or clusters, and a non-zero
   value for SupportLifetime is used, all TLS server instances MUST support serving both this
   extension and <xref target="dnssec-chain-extension"/>. As long as no TLS service instance
   uses a non-zero value, both TLS extensions can be rolled out incrementally without any TLS
   clients commiting to either TLS extension.
  </t>
  </section>

  <section title="Security Considerations">
    <t>
      This draft specifies a TLS extension that adds downgrade
      protection for another TLS extension, <xref target="dnssec-chain-extension"/>.
      Without the downgrade protection specified in this TLS extension, the
      only effect of deploying <xref target="dnssec-chain-extension"/> is
      to reduce TLS security from the standard "WebPKI security" to
      "WebPKI or DANE, whichever is weaker".
    </t>

    <t>
      This draft dictates that <xref target="dnssec-chain-extension"/> MUST
      only be used in combination with this TLS extension, whose only content
      is a two byte SupportLifetime value. A value of 0 prohibits the TLS client
      from unilaterally requiring ongoing use of both TLS extensions based on prior
      observation of their use (pinning). A non-zero value is the value in hours
      for which this TLS extension as well as <xref target="dnssec-chain-extension"/>
      MUST appear in subsequent TLS handshakes to the same hostname and port. If this TLS
      extention or <xref target="dnssec-chain-extension"/> is missing from the TLS
      handshake within this observed pinning time, the TLS client MUST assume it
      is under attack and abort the TLS connection.
    </t>
  </section>


  <section title="IANA Considerations">

    <t>This extension requires the registration of a new
      value in the TLS ExtensionsType registry.  The value
      requested from IANA is [TBD], and the extension should
      be marked "Recommended" in accordance with "IANA Registry
      Updates for TLS and DTLS" <xref target="TLSIANA"/>.
    </t>

  </section> <!-- iana considerations -->


</middle>

<back>

  <references title="Normative References">
    &rfc2119;
    &rfc8174;
    <reference anchor="dnssec-chain-extension"
        target="https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07">
        <front>
          <title>A DANE Record and DNSSEC Authentication Chain Extension for TLS</title>
          <author fullname="Melinda Shore" initials="M" surname="Shore" />
          <author fullname="Richard Barnes" initials="R" surname="Barnes" />
          <author fullname="Shumon Huque" initials="S" surname="Hugue" />
          <author fullname="Willem Toorop" initials="W" surname="Toorop" />
          <date year="2018" month="March" day="21"/>
        </front>
    </reference>
    <reference anchor="TLSIANA"
        target="https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates">
        <front>
          <title>IANA Registry Updates for TLS and DTLS</title>
          <author fullname="Joe Salowey" initials="J" surname="Salowey" />
          <author fullname="Sean Turner" initials="S" surname="Turner" />
          <date />
        </front>
    </reference>
  </references>


</back>
</rfc>
