One document matched: draft-thomson-http-omnomnom-00.xml

<?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.20 -->

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

<rfc ipr="trust200902" docName="draft-thomson-http-omnomnom-00" category="std">

<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc docmapping="yes"?>

  <front>
    <title abbrev="EAT HTTP Cookies">Expiring Aggressively Those HTTP Cookies</title>

    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Mozilla</organization>
      <address>
        <email>martin.thomson@gmail.com</email>
      </address>
    </author>
    <author initials="C." surname="Peterson" fullname="Chris Peterson">
      <organization>Mozilla</organization>
      <address>
        <email>cpeterson@mozilla.com</email>
      </address>
    </author>

    <date year="2016"/>

    <area>General</area>
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>HTTP Cookies that are sent over connections without confidentiality and
integrity protection are vulnerable to theft.  Such cookies should be expired
aggressively.</t>



    </abstract>


  </front>

  <middle>


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

<t>HTTP cookies <xref target="RFC6265"></xref> provide a means of persisting server state between
multiple requests.  This feature is widely used on both HTTP <xref target="RFC7230"></xref> and HTTPS
<xref target="RFC2818"></xref> requests.</t>

<t>The authority for “http://” resources (see Section 9.1 of <xref target="RFC7230"></xref>) derives
from insecure sources: notably the network and the DNS (absent DNSSEC).  This
situation might change over time.  As persistent state, cookies create a way for
an attacker to link requests.  The information that a cookie holds might also be
valuable to that attacker in some way.</t>

<t>To limit the effectiveness of attacks on cleartext communications <xref target="RFC7258"></xref>,
user agents are encouraged to limit the persistence of cookies that are set
over insecure connections.</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="expire-cookies" title="Expire Cookies">

<t>Cookies that are set using insecure channels (i.e., HTTP over cleartext TCP),
MUST have a short time limit on the time that they are persisted.   For
instance, such cookies might only persist until the user closes their browser.</t>

<t>If a user agent detects a change in network conditions it SHOULD remove any
cookies that were established using insecure channels.</t>

<t>Alternatives:</t>

<t><list style="symbols">
  <t>In the investigation into this change, it was suggested that cookies without
the “Secure” flag might be given the same treatment.  However, this resulted
in a far greater number of cookies being affected and some interoperability
problems as a result.</t>
  <t>This change might be limited to cookies that are set in third-party contexts.
See [I-D.west-first-party-cookies].  <vspace blankLines='1'/>
Limiting access to third-party cookies in this fashion could have the
secondary effect of encouraging providers of third-party content to move to
HTTPS.  This removes that content as a barrier to the adoption of HTTPS for
the sites that include that content.</t>
</list></t>

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

<t>This document describes an improvement that could be a security improvement.
However, this is not without risks.  For cookies that are used as a substitute
for logins, more regular clearing of a login cookie could expose the primary
authentication token (for instance, a password) to more network attackers as a
result of being entered more often.</t>

<t>Clearing login tokens could also cause a degree of user annoyance, as login
information is lost.  Such annoyance manifests in many subtle ways.</t>

<t>Limiting the change to third-party contexts as suggested above might reduce
these risks, though with lesser overall impact.</t>

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

<t>This document makes no request of IANA.</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='RFC7230' target='http://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
</reference>



<reference  anchor='RFC6265' target='http://www.rfc-editor.org/info/rfc6265'>
<front>
<title>HTTP State Management Mechanism</title>
<author initials='A.' surname='Barth' fullname='A. Barth'><organization /></author>
<date year='2011' month='April' />
<abstract><t>This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol.  Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet.  This document obsoletes RFC 2965.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6265'/>
<seriesInfo name='DOI' value='10.17487/RFC6265'/>
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor='RFC2818' target='http://www.rfc-editor.org/info/rfc2818'>
<front>
<title>HTTP Over TLS</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2000' month='May' />
<abstract><t>This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='2818'/>
<seriesInfo name='DOI' value='10.17487/RFC2818'/>
</reference>



<reference  anchor='RFC7258' target='http://www.rfc-editor.org/info/rfc7258'>
<front>
<title>Pervasive Monitoring Is an Attack</title>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<date year='2014' month='May' />
<abstract><t>Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.</t></abstract>
</front>
<seriesInfo name='BCP' value='188'/>
<seriesInfo name='RFC' value='7258'/>
<seriesInfo name='DOI' value='10.17487/RFC7258'/>
</reference>




    </references>


<section anchor="acknowledgements" title="Acknowledgements">

<t>Henri Sivonen first suggested that non-Secure cookies be made ephemeral.
Chris Peterson did much of the initial investigation and work.  See
<eref target="https://bugzilla.mozilla.org/show_bug.cgi?id=1160368" /> for details.</t>

</section>


  </back>
</rfc>