Stephen Farrell | 31 Oct 15:19 2014
Picon
Picon

Conflict review for draft-dthakore-tls-authz


Hi,

The authors of draft-dthakore-tls-authz [1] presented their work
to the TLS WG some time ago and IIRC there wasn't interest
in pursuing that. So as is fairly common in such cases, they have
asked the independent submissions editor (ISE) to publish their
work as an RFC in the independent stream.

As part of that, the IESG do a conflict review [2] to determine
if the work conflicts with ongoing IETF work, as described in
RFC 5742 [3]. (See section 3 of that for the possible responses
the IESG can give.)

So, please let me know (say by Nov 17) if you think that this
work does conflict with the TLS WG's efforts. (Silence is fine
if you think it does not conflict.)

If you have technical comments on the draft itself, then I'm
sure the authors and the ISE would be interested in those.

If you have process questions about this, feel free to ask me
or the WG chairs.

Thanks,
S.

[1] https://datatracker.ietf.org/doc/draft-dthakore-tls-authz/
[2] https://datatracker.ietf.org/doc/conflict-review-dthakore-tls-authz/
[3] https://tools.ietf.org/html/rfc5742
(Continue reading)

Bodo Moeller | 29 Oct 14:04 2014
Picon

Working draft for draft-ietf-tls-downgrade-scsv-01 (and draft-bmoeller-tls-falsestart-01)

It's past the cut-off for IETF 91 submissions and also none of the authors may make there, but here (attached) are working drafts for new revisions of draft-ietf-tls-downgrade-scsv and draft-bmoeller-tls-falsestart. (No changes to the TLS_FALLBACK_SCSV mechanism, but various clarifications.)

I plan to submit these on November 10 before the main IETF meeting starts, when the I-D submission tool is reopened.

Bodo


Network Working Group                                         B. Moeller
Internet-Draft                                                A. Langley
Updates: 2246, 4346, 5246 (if approved)                           Google
Intended status: Standards Track                        October 29, 2014
Expires: May 2, 2015

TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol
                           Downgrade Attacks
                 DRAFT-draft-ietf-tls-downgrade-scsv-01

Abstract

   This document defines a Signaling Cipher Suite Value (SCSV) that
   prevents protocol downgrade attacks on the Transport Layer Security
   (TLS) protocol.  It updates RFC 2246, RFC 4346, and RFC 5246.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 2, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Moeller & Langley          Expires May 2, 2015                  [Page 1]

Internet-Draft              TLS Fallback SCSV               October 2014

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Protocol values . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Server behavior . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Client behavior . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Operational Considerations  . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   To work around interoperability problems with legacy servers, many
   TLS client implementations do not rely on the TLS protocol version
   negotiation mechanism alone, but will intentionally reconnect using a
   downgraded protocol if initial handshake attempts fail.  Such clients
   may fall back to connections in which they announce a version as low
   as TLS 1.0 (or even its predecessor, SSL 3.0) as the highest
   supported version.

   While such fallback retries can be a useful last resort for
   connections to actual legacy servers, there's a risk that active
   attackers could exploit the downgrade strategy to weaken the
   cryptographic security of connections.  Also, handshake errors due to
   network glitches could similarly be misinterpreted as interaction
   with a legacy server and result in a protocol downgrade.

   All unnecessary protocol downgrades are undesirable (e.g., from TLS
   1.2 to TLS 1.1 if both the client and the server actually do support
   TLS 1.2); they can be particularly critical if they mean losing the
   TLS extension feature (when downgrading to SSL 3.0).  This document
   defines a Signaling Cipher Suite Value (SCSV) that can be employed to
   prevent unintended protocol downgrades between clients and servers
   that comply to this document, by having the client indicate that the
   current connection attempt is merely a fallback, and by having the
   server return a fatal alert if it detects an inappropriate fallback.
   (The alert does not necessarily indicate an intentional downgrade
   attack, since network glitches too could result in inappropriate
   fallback retries.)

   This specification applies to implementations of TLS 1.0 [RFC2246],
   TLS 1.1 [RFC4346], and TLS 1.2 [RFC5246].  (It is particularly
   relevant if such implementations also include support for predecessor

Moeller & Langley          Expires May 2, 2015                  [Page 2]

Internet-Draft              TLS Fallback SCSV               October 2014

   protocol SSL 3.0 [RFC6101].)  It can be applied similarly to later
   protocol versions.

   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 [RFC2119].

2.  Protocol values

   This document defines a new TLS cipher suite value:

        TLS_FALLBACK_SCSV          {0x56, 0x00}

   This is a signaling cipher suite value (SCSV), i.e., it does not
   actually correspond to a suite of cryptosystems, and it can never be
   selected by the server in the handshake; rather, its presence in the
   Client Hello message serves as a backwards-compatible signal from the
   client to the server.

   This document also allocates a new alert value in the TLS Alert
   Registry [RFC5246]:

        enum {
          /* ... */
          inappropriate_fallback(86),
          /* ... */
          (255)
        } AlertDescription;

   This alert is only generated by servers, as described in Section 3.
   It is always fatal.

3.  Server behavior

   This section specifies server behavior when receiving the
   TLS_FALLBACK_SCSV cipher suite from a client in
   ClientHello.cipher_suites.

   o  If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the
      highest protocol version supported by the server is higher than
      the version indicated in ClientHello.client_version, the server
      MUST respond with a fatal inappropriate_fallback alert.

   o  Otherwise (either TLS_FALLBACK_SCSV does not appear, or it appears
      and the client's protocol version is at least the highest protocol
      version supported by the server), the server proceeds with the
      handshake as usual.

Moeller & Langley          Expires May 2, 2015                  [Page 3]

Internet-Draft              TLS Fallback SCSV               October 2014

   (A protocol version is supported by the server if, in response to
   appropriate Client Hello messages, the server would use it for
   ServerHello.server_version.  If a particular protocol version is
   implemented but completely disabled by server settings, it is not
   considered supported.  For example, if the implementation's highest
   protocol version is TLS 1.2 but the server operator has disabled this
   version, a TLS 1.1 Client Hello with TLS_FALLBACK_SCSV does not
   warrant responding with an inappopriate_fallback alert.)

4.  Client behavior

   The TLS_FALLBACK_SCSV cipher suite value is meant for use by clients
   that repeat a connection attempt with a downgraded protocol (perform
   a "fallback retry") in order to work around interoperability problems
   with legacy servers.

   o  If a client sends a ClientHello.client_version containing a lower
      value than the latest (highest-valued) version supported by the
      client, it SHOULD include the TLS_FALLBACK_SCSV cipher suite value
      in ClientHello.cipher_suites.  (Since the cipher suite list in the
      ClientHello is ordered by preference, with the client's favorite
      choice first, signaling cipher suite values will generally appear
      after all cipher suites that the client actually intends to
      negotiate.)

   o  As an exception to the above, when a client intends to resume a
      session and sets ClientHello.client_version to the protocol
      version negotiated for that session, it MUST NOT include
      TLS_FALLBACK_SCSV in ClientHello.cipher_suites.  (In this case, it
      is assumed that the client already knows the highest protocol
      version supported by the server: see [RFC5246], Appendix E.1.)

   o  If a client sets ClientHello.client_version to its highest
      supported protocol version, it MUST NOT include TLS_FALLBACK_SCSV
      in ClientHello.cipher_suites.

   (A protocol version is supported by the client if the client normally
   attempts to use it in handshakes.  If a particular protocol version
   is implemented but completely disabled by client settings, it is not
   considered supported.  For example, if the implementation's highest
   protocol version is TLS 1.2 but the user has disabled this version, a
   TLS 1.1 handshake is expected and does not warrant sending
   TLS_FALLBACK_SCSV.)

   If a client keeps track of the highest protocol version apparently
   supported by a particular server for use in

Moeller & Langley          Expires May 2, 2015                  [Page 4]

Internet-Draft              TLS Fallback SCSV               October 2014

   ClientHello.client_version later, then if the client receives an
   inappropriate_fallback alert from that server, it MUST clear the
   memorized highest supported protocol version.  (Without the alert, it
   is a good idea -- but outside of the scope of this document -- for
   clients to clear that state after a time-out, since the server's
   highest protocol version could change over time.)

   For clients that use client-side TLS False Start [false-start], it is
   important to note that the TLS_FALLBACK_SCSV mechansim cannot protect
   the first round of application data sent by the client: refer to the
   Security Considerations in [false-start], Section 6.

5.  Operational Considerations

   Updating legacy server clusters to simultaneously add support for
   newer protocol versions and support for TLS_FALLBACK_SCSV can have
   complications, if the legacy server implementation is not "version-
   tolerant" (cannot properly handle Client Hello messages for newer
   protocol versions): fallback retries required for interoperability
   with old server nodes might be rejected by updated server nodes.

   Updating the server cluster in two consecutive steps makes this safe:
   first, update the server software but leave the highest supported
   version unchanged (by disabling newer versions in server settings);
   after that step has concluded, change server settings to allow new
   protocol versions.

6.  Security Considerations

   Section 4 does not require client implementations to send
   TLS_FALLBACK_SCSV in any particular case, it merely recommends it;
   behavior can be adapted according to the client's security needs.
   For example, during the initial deployment of a new protocol version
   (when some interoperability problems may have to be expected),
   smoothly falling back to the previous protocol version in case of
   problems may be preferrable to potentially not being able to connect
   at all: so TLS_FALLBACK_SCSV could be omitted for this particular
   protocol downgrade step.

   However, it is strongly recommended to send TLS_FALLBACK_SCSV when
   downgrading to SSL 3.0 as the CBC cipher suites in SSL 3.0 have
   weaknesses that cannot be addressed by implementation workarounds
   like the remaining weaknesses in later (TLS) protocol versions.

Moeller & Langley          Expires May 2, 2015                  [Page 5]

Internet-Draft              TLS Fallback SCSV               October 2014

7.  IANA Considerations

   [[ NOTE IN DRAFT: The requested registry allocation requires
   Standards Action, i.e., will only be official with the IESG's
   Standards Track RFC approval.  Since this document is currently an
   Internet-Draft, IANA so far has in fact not added the cipher suite
   number to the registry. ]]

   IANA has added TLS cipher suite number 0x56,0x00 with name
   TLS_FALLBACK_SCSV to the TLS Cipher Suite registry.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

8.2.  Informative References

   [RFC6101]  Freier, A., Karlton, P., and P. Kocher, "The Secure
              Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
              August 2011.

   [false-start]
              Langley, A., Modadugu, N., and B. Moeller, "Transport
              Layer Security (TLS) False Start", Work in Progress,
              draft-bmoeller-tls-falsestart-01, November 2014.

Appendix A.  Acknowledgements

   This specification was inspired by an earlier proposal by Eric
   Rescorla.  We also thank Martin Thomson, Brian Smith, and others in
   the TLS Working Group for their feedback and suggestions.

Moeller & Langley          Expires May 2, 2015                  [Page 6]

Internet-Draft              TLS Fallback SCSV               October 2014

Authors' Addresses

   Bodo Moeller
   Google Switzerland GmbH
   Brandschenkestrasse 110
   Zurich  8002
   Switzerland

   Email: bmoeller <at> acm.org

   Adam Langley
   Google Inc.
   345 Spear St
   San Francisco, CA  94105
   USA

   Email: agl <at> google.com

Moeller & Langley          Expires May 2, 2015                  [Page 7]

TLS Working Group                                             A. Langley
Internet-Draft                                                    Google
Intended status: Experimental                                N. Modadugu
Expires: May 2, 2015                                         Independent
                                                              B. Moeller
                                                                  Google
                                                        October 29, 2014

               Transport Layer Security (TLS) False Start
                 DRAFT-draft-bmoeller-tls-falsestart-01

Abstract

   This document specifies an optional behavior of TLS implementations,
   dubbed False Start.  It affects only protocol timing, not on-the-wire
   protocol data, and can be implemented unilaterally.  The TLS False
   Start feature leads to a latency reduction of one round trip for
   certain handshakes.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 2, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must

Langley, et al.            Expires May 2, 2015                  [Page 1]

Internet-Draft               TLS False Start                October 2014

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  False Start Compatibility . . . . . . . . . . . . . . . . . .   5
   4.  Client-side False Start . . . . . . . . . . . . . . . . . . .   5
   5.  Server-side False Start . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     6.1.  Symmetric Cipher  . . . . . . . . . . . . . . . . . . . .   7
     6.2.  Protocol Version  . . . . . . . . . . . . . . . . . . . .   8
     6.3.  Key Exchange and Client Certificate Type  . . . . . . . .   8
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Appendix A.  Implementation Notes . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Requirements Notation

   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 RFC 2119 [RFC2119].

2.  Introduction

   A full TLS handshake as specified in [RFC5246] requires two full
   protocol rounds (four flights) before the handshake is complete and
   the protocol parties may begin to send application data.  Thus, using
   TLS can add a latency penalty of two network round-trip times for
   application protocols in which the client sends data first, such as
   HTTP [RFC2616].  An abbreviated handshake (resuming an earlier TLS
   session) is complete after three flights, thus adding just one round-
   trip time if the client sends application data first.

Langley, et al.            Expires May 2, 2015                  [Page 2]

Internet-Draft               TLS False Start                October 2014

      Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

        Figure 1 [RFC5246].  Message flow for a full handshake

Langley, et al.            Expires May 2, 2015                  [Page 3]

Internet-Draft               TLS False Start                October 2014

      Client                                                Server

      ClientHello                   -------->
                                                       ServerHello
                                                [ChangeCipherSpec]
                                    <--------             Finished
      [ChangeCipherSpec]
      Finished                      -------->
      Application Data              <------->     Application Data

     Figure 2 [RFC5246].  Message flow for an abbreviated handshake

   This document describes a technique that alleviates the latency
   burden imposed by TLS: the TLS False Start.  If certain conditions
   are met, application data can be sent when the handshake is only
   partially complete -- i.e., when the sender has sent its own
   "ChangeCipherSpec" and "Finished" messages (thus having updated its
   TLS Record Protocol write state as negotiated in the handshake), but
   has yet to receive the other side's "ChangeCipherSpec" and "Finished"
   messages.  (By section 7.4.9 of [RFC5246], each party would have to
   delay sending application data until it has received and validated
   the other side's "Finished" message.)  This achieves an improvement
   of one round-trip time

   o  for full handshakes if the client sends application data first,

   o  for abbreviated handshakes if the server sends application data
      first.

   Accordingly, the latency penalty for using TLS with HTTP can be kept
   at one round-trip time regardless of whether a full handshake or an
   abbreviated handshake takes place.

   In a False Start, when a party sends application data before it has
   received and verified the other party's "Finished" message, there are
   two possible outcomes:

   o  The handshake completes successfully: Once both "Finished"
      messages have been received and verified, this retroactively
      validates the handshake.  In this case, the transcript of protocol
      data carried over the transport underlying TLS will look as usual,
      apart from the different timing.

   o  The handshake fails: If a party does not receive the other side's
      "Finished" message, or if the "Finished" message's contents are
      not correct, the handshake never gets validated.  This means that
      an attacker may have removed, changed, or injected handshake

Langley, et al.            Expires May 2, 2015                  [Page 4]

Internet-Draft               TLS False Start                October 2014

      messages.  In this case, data has been sent over the underlying
      transport that would not have been sent without the False Start.

   The latter scenario makes it necessary to restrict when a False Start
   is allowed, as described in this document.  Section 3 considers basic
   requirements for using False Start.  Section 4 and Section 5 specify
   the behavior for clients and servers, respectively, referring to
   important security considerations in Section 6.

3.  False Start Compatibility

   TLS False Start as described in detail in the subsequent sections, if
   implemented, is an optional feature.

   A TLS implementation (not necessarily offering the False Start option
   itself) is defined to be "False Start compatible" if it tolerates
   receiving TLS records on the transport connection early, before the
   protocol has reached the state to process these.  To successfully use
   False Start in a TLS connection, the other side has to be False Start
   compatible.  Out-of-band knowledge that the peer is False Start
   compatible may be available, e.g. if this is mandated by specific
   application profile standards.  As discussed in Appendix A, the
   requirement for False Start compatibility does not pose a hindrance
   in practice.

4.  Client-side False Start

   This section specifies a change to the behavior of TLS client
   implementations in full TLS handshakes.

   When the client has sent its "ChangeCipherSpec" and "Finished"
   messages, its default behavior following [RFC5246] is to not send
   application data until it has received the server's
   "ChangeCipherSpec" and "Finished" messages, which completes the
   handshake.  With the False Start protocol modification, the client
   MAY send application data earlier (under the new Cipher Spec) if each
   of the following conditions is satisfied:

   o  The application layer has requested the TLS False Start option.

   o  The symmetric cipher defined by the cipher suite negotiated in
      this handshake has been whitelisted for use with False Start
      according to the Security Considerations in Section 6.1.

   o  The protocol version chosen by ServerHello.server_version has been
      whitelisted for use with False Start according to the Security
      Considerations in Section 6.2.

Langley, et al.            Expires May 2, 2015                  [Page 5]

Internet-Draft               TLS False Start                October 2014

   o  The key exchange method defined by the cipher suite negotiated in
      this handshake has been whitelisted for use with False Start
      according to the Security Considerations in Section 6.3.

   o  In the case of a handshake with client authentication, the client
      certificate type has been whitelisted for use with False Start
      according to the Security Considerations in Section 6.3.

   The rules for receiving application data from the server remain
   unchanged.

   Note that the TLS client cannot infer the presence of an
   authenticated server until all handshake messages have been received.
   With False Start, unlike with the default handshake behavior,
   applications are able to send data before this point has been
   reached: from an application point of view, being able to send data
   does not imply that an authenticated peer is present.  Accordingly,
   it is recommended that TLS implementations allow the application
   layer to query whether the handshake has completed.

5.  Server-side False Start

   This section specifies a change to the behavior of TLS server
   implementations in abbreviated TLS handshakes.

   When the server has sent its "ChangeCipherSpec" and "Finished"
   messages, its default behavior following [RFC5246] is not to send
   application data until it has received the client's
   "ChangeCipherSpec" and "Finished" messages, which completes the
   handshake.  With the False Start protocol modification, the server
   MAY send application data earlier (under the new Cipher Spec) if each
   of the following conditions is satisfied:

   o  The application layer has requested the TLS False Start option.

   o  The symmetric cipher defined by the cipher suite of the session
      being resumed has been whitelisted for use with False Start
      according to the Security Considerations in Section 6.1.

   The rules for receiving application data from the client remain
   unchanged.

   Note that the TLS server cannot infer the presence of an
   authenticated client until all handshake messages have been received.
   With False Start, unlike with the default handshake behavior,
   applications are able to send data before this point has been
   reached: from an application point of view, being able to send data
   does not imply that an authenticated peer is present.  Accordingly,

Langley, et al.            Expires May 2, 2015                  [Page 6]

Internet-Draft               TLS False Start                October 2014

   it is recommended that TLS implementations allow the application
   layer to query whether the handshake has completed.

6.  Security Considerations

   In a TLS handshake, the "Finished" messages serve to validate the
   entire handshake.  These messages are based on a hash of the
   handshake so far processed by a PRF keyed with the new master secret
   (serving as a MAC), and are also sent under the new Cipher Spec with
   its keyed MAC, where the MAC key again is derived from the master
   secret.  The protocol design relies on the assumption that any server
   and/or client authentication done during the handshake carries over
   to this.  While an attacker could, for example, have changed the
   cipher suite list sent by the client to the server and thus
   influenced cipher suite selection (presumably towards a less secure
   choice) or could have made other modifications to handshake messages
   in transmission, the attacker would not be able to round off the
   modified handshake with a valid "Finished" message: every TLS cipher
   suite is presumed to key the PRF appropriately to ensure
   unforgeability.  Once the handshake has been validated by verifying
   the "Finished" messages, this confirms that the handshake has not
   been tampered with, thus bootstrapping secure encryption (using
   algorithms as negotiated) from secure authentication.

   Using False Start interferes with this approach of bootstrapping
   secure encryption from secure authentication, as application data may
   have already been sent before "Finished" validation confirms that the
   handshake has not been tampered with -- so there is generally no hope
   to be sure that communication with the expected peer is indeed taking
   place during the False Start.  Instead, the security goal is to
   ensure that if anyone at all can decrypt the application data sent in
   a False Start, this must be the legitimate peer: while an attacker
   could be influencing the handshake (restricting cipher suite
   selection, modifying key exchange messages, etc.), the attacker
   should not be able to benefit from this.  The TLS protocol already
   relies on such a security property for authentication -- with False
   Start, the same is needed for encryption.  This motivates the
   following rules.

6.1.  Symmetric Cipher

   Clients and servers MUST NOT use the False Start protocol
   modification in a handshake unless the cipher suite uses a symmetric
   cipher that is considered cryptographically strong.

   Implementations may have their own classification of ciphers (and may
   additionally allow the application layer to provide a
   classification), but generally only symmetric ciphers with an

Langley, et al.            Expires May 2, 2015                  [Page 7]

Internet-Draft               TLS False Start                October 2014

   effective key length of 128 bits or more can be considered strong.
   Also, various ciphers specified for use with TLS are known to have
   cryptographic weaknesses regardless of key length (none of the
   ciphers specified in [RFC4492] and [RFC5246] can be recommended for
   use with False Start).  The AES_128_GCM_SHA256 or AES_256_GCM_SHA384
   ciphers specified in [RFC5288] and [RFC5289] can be considered
   sufficiently strong for most uses.  Implementations that support
   additional cipher suites have to be careful to whitelist only
   suitable symmetric ciphers; if in doubt, False Start should not be
   used with a given symmetric cipher.

   While an attacker can change handshake messages to force a downgrade
   to a less secure symmetric cipher than otherwise would have been
   chosen, this rule ensures that in such a downgrade attack no
   application data will be sent under an insecure symmetric cipher.
   With respect to server-side False Start, if a client has negotiated a
   TLS session using weak symmetric cryptography, this rule prevents
   attackers from seeing the server encrypt more data under this session
   than normally (if an attacker makes up a "ClientHello" message asking
   to resume such a session, no False Start will happen).

6.2.  Protocol Version

   Clients MUST NOT use the False Start protocol modification in a
   handshake unless the protocol version chosen by
   ServerHello.server_version has been whitelisted for this use.

   Generally, implementations should whitelist only the protocol
   version(s) for which they would not send TLS_FALLBACK_SCSV
   [downgrade-scsv].

   The details of nominally identical cipher suites can differ between
   protocol versions, so this reinforces Section 6.1.

6.3.  Key Exchange and Client Certificate Type

   Clients MUST NOT use the False Start protocol modification in a
   handshake unless the cipher suite uses a key exchange method that has
   been whitelisted for this use.  Furthermore, when using client
   authentication, clients MUST NOT use the False Start protocol
   modification unless the client certificate type has been whitelisted
   for this use.

   Implementations may have their own whitelists of key exchange methods
   and client certificate types (and may additionally allow the
   application layer to specify whitelists).  Generally, out of the
   options from [RFC5246] and [RFC4492], the following whitelists are
   recommended:

Langley, et al.            Expires May 2, 2015                  [Page 8]

Internet-Draft               TLS False Start                October 2014

   o  Key exchange methods: DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA

   o  Client certificate types: rsa_sign, dss_sign, ecdsa_sign (or no
      client authentication)

   However, if an implementation that supports only key exchange methods
   from [RFC5246] and [RFC4492] does not support any of the above key
   exchange methods, all of its supported key exchange methods can be
   whitelisted for False Start use.  Care is required with any
   additional key exchange methods or client certificate types, as these
   may not have similar properties.

   The recommended whitelists are such that if cryptographic algorithms
   suitable for forward secrecy would possibly be negotiated, no False
   Start will take place if the current handshake fails to provide
   forward secrecy.  (Forward secrecy can be achieved using ephemeral
   Diffie-Hellman or ephemeral Elliptic-Curve Diffie-Hellman; there is
   no forward secrecy when a using key exchange method of RSA, RSA_PSK,
   DH_DSS, DH_RSA, ECDH_ECDSA, or ECDH_RSA, or a client certificate type
   of rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, or ecdsa_fixed_ecdh.)
   As usual, the benefits of forward secrecy may need to be balanced
   against efficiency, and accordingly even implementations that support
   the above key exchange methods might whitelist further key exchange
   methods and client certificate types from [RFC5246] and [RFC4492].

7.  Acknowledgments

   The authors wish to thank Wan-Teh Chang, Ben Laurie, Eric Rescorla,
   and Brian Smith for their input.

8.  IANA Considerations

   None.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
              for Transport Layer Security (TLS)", RFC 4492, May 2006.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

Langley, et al.            Expires May 2, 2015                  [Page 9]

Internet-Draft               TLS False Start                October 2014

   [RFC5288]  Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
              Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
              August 2008.

   [RFC5289]  Rescorla, E., "TLS Elliptic Curve Cipher Suites with
              SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
              August 2008.

9.2.  Informative References

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [downgrade-scsv]
              Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
              Suite Value (SCSV) for Preventing Protocol Downgrade
              Attacks", Work in Progress, draft-ietf-tls-downgrade-
              scsv-01, November 2014.

Appendix A.  Implementation Notes

   TLS False Start is a modification to the TLS protocol, and some
   implementations that conform to [RFC5246] may have problems
   interacting with implementations that use the False Start
   modification.  If the peer uses a False Start, application data
   records may be received directly following the peer's "Finished"
   message, before the TLS implementation has sent its own "Finished"
   message.  False Start compatibility as defined in Section 3 ensures
   that these records with application data will simply remain buffered
   for later processing.

   A False Start compatible TLS implementation does not have to be aware
   of the False Start concept, and is certainly not expected to detect
   whether a False Start handshake is currently taking place: thanks to
   transport layer buffering, typical implementations will be False
   Start compatible without having been designed for it.

Authors' Addresses

   Adam Langley
   Google Inc.
   345 Spear St
   San Francisco, CA  94105
   USA

   Email: agl <at> google.com

Langley, et al.            Expires May 2, 2015                 [Page 10]

Internet-Draft               TLS False Start                October 2014

   Nagendra Modadugu
   Independent

   Email: nagendra <at> cs.stanford.edu

   Bodo Moeller
   Google Switzerland GmbH
   Brandschenkestrasse 110
   Zurich  8002
   Switzerland

   Email: bmoeller <at> acm.org

Langley, et al.            Expires May 2, 2015                 [Page 11]
_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hannes Tschofenig | 28 Oct 07:22 2014
Picon
Picon

Updated TLS Cached Info Draft

 Hi all,

as a result of the WGLC the cached info draft got a few good review
comments. I have tried to address them with a new document update
(version -17).

Since I missed the draft submission deadline you can find the document
here:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-17.txt

I will respond to the review comments directly but here is a short summary:

* Simplified the exchange (as suggested by Ekr).
* Incorporated the optimizations suggested by Ekr regarding the
certificate_authority structure
* Required a collision resistant hash function.
* Clarifications throughout the document.

Ciao
Hannes

_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Yuhong Bao | 28 Oct 03:05 2014
Picon

Prohibiting SSL 3.0

I hope that a Internet-Draft prohibiting SSL 3.0 will be next. Maybe make an exception for things like
browser download sites (it is easy to enable TLS 1.0 in IE6 but for these kind of sites it is probably not
worth the effort).

Yuhong Bao 		 	   		  
internet-drafts | 27 Oct 23:14 2014
Picon

I-D Action: draft-ietf-tls-tls13-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the IETF.

        Title           : The Transport Layer Security (TLS) Protocol Version 1.3
        Authors         : Tim Dierks
                          Eric Rescorla
	Filename        : draft-ietf-tls-tls13-03.txt
	Pages           : 93
	Date            : 2014-10-27

Abstract:
   This document specifies Version 1.3 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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-tls13-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Joseph Salowey | 27 Oct 03:58 2014
Picon

Summary of RC4 Discussions

Judging from the discussion on the list and from the interim meeting report I think we have consensus to deprecate RC4.  There are different views on when to deprecate RC4 with the majority view seeming to fall within the next few years.   I am going to recommend that the IESG proceed with publication of the draft as is.  

Thanks,

Joe
_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Joseph Salowey | 27 Oct 03:40 2014
Picon

November Interim and IETF 91 Meeting details

Below are the details for the upcoming meetings along with a very drafty agenda:

TLS November 2014 Interim Meeting

November 9, 2014, 9:30 - 13:30 -  Kahili room

--------------------------------------------------------------------


Agenda (Draft)

---------------------

Focus on TLS 1.3 topics (draft-ietf-tls-tls13)

  1. 1.3 Session Resumption

  2. 1.3 Key Refresh/Client auth

  3. 1.3 (0-RTT)



IETF 91 TLS Meeting

November 13, 2014, 9 - 11:30 - Coral 5

------------------------------


Agenda (Draft)

--------------------

  1. RC4 (if necessary)

draft-ietf-tls-prohibiting-rc4

  1. Downgrade SCSV

draft-ietf-tls-downgrade-scsv

  1. Session Hash

draft-ietf-tls-session-hash

  1. Finite Field DHE negotiation

draft-ietf-tls-negotiated-ff-dhe

  1. TLS 1.3 Topics continued/Recap

draft-ietf-tls-tls13


_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Picon

Fw: I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt


--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street, Lexington, MA 02420-9185       

Web:  http://www.ll.mit.edu/CST/
MIT LL Root CA:  <https://www.ll.mit.edu/labcertificateauthority.html>

----- Original Message -----
From: Blumenthal, Uri - 0558 - MITLL
Sent: Friday, October 24, 2014 10:50 AM
To: 'rsalz <at> akamai.com' <rsalz <at> akamai.com>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

I disagree. In case of SMTP STARTTLS something *is* better than nothing. It is not about false sense of
security - it is about making the adversary's job harder when possible as much as possible; realizing that
sometimes what's possible is not going to be AES256-hard.

P.S. In that case/scenario even ROT13 is better than nothing.

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street, Lexington, MA 02420-9185       

Web:  http://www.ll.mit.edu/CST/
MIT LL Root CA:  <https://www.ll.mit.edu/labcertificateauthority.html>

----- Original Message -----
From: Salz, Rich [mailto:rsalz <at> akamai.com]
Sent: Friday, October 24, 2014 10:31 AM
To: tls <at> ietf.org <tls <at> ietf.org>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

> Leaving a cipher suite out is only practical once it is no longer the best shared
> cipher with any peers.  

I don't agree with this blanket statement.  Sometimes nothing trumps "something is better than nothing."

When the IETF's leading cryptographers say not to use something, then you're better off with plaintext
than a false sense of security for your users.

	/r$

--  
Principal Security Engineer, Akamai Technologies
IM: rsalz <at> jabber.me Twitter: RichSalz

_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Nikos Mavrogiannopoulos | 23 Oct 15:36 2014
Picon

rfc7366: is encrypt-then-mac implemented?

Hello,
 Is there some public server implementing rfc7366? At some point the
server at eid.vx4.net was sent as one, but it doesn't seem to implement
the protocol in the published rfc (the NSS people seem to have noticed
that [0], and my tests agree).

regards,
Nikos

[0]. https://bugzilla.mozilla.org/show_bug.cgi?id=972145
Martin Thomson | 22 Oct 12:04 2014
Picon

Summary of discussion regarding spontaneuous authentication

The update proposal that ekr sent around was discussed.

The primary concern was that the properties of the connection were
considered to change with respect to authentication.  Any data
received before the authentication, or messages that appear partially
before and partially after would have ambiguous properties.

Concerns were raised that having the authentication attest to data
that was sent prior to the authentication would expose us to a variety
of attacks that relied on confusion about the state of the connection.
There was also a concern that this would be difficult to analyse.

It was pointed out that update was still interesting, but only from a
rekeying perspective, because that had far lesser risks and no real
API implications.

If we decided to continue with Update, then we would have a place to
add a future extension that re-enabled this feature.

I noted that the use case that renegotiation provides was not going to
be supported with the proposed Update message, since there was no
analogue for the HelloRequest message.

All of this led to the decision not to pursue spontaneous authentication.
Eric Rescorla | 21 Oct 16:52 2014

Should we require compressed points

https://github.com/tlswg/tls13-spec/issues/80

Today we discussed the possibility of requiring support for compressed points
in TLS 1.3 now that the IPR has expired.

Specifically, I propose that for TLS 1.3, we:

- Use only compressed points for the existing curves (and presumably
  whatever superior format is defined for the CFRG-recommended
  curves, as appropriate).

- Deprecate the Supported Point Formats extension for TLS 1.3


For RFC 4492-bis, we might also consider requiring support for compressed
points as well as uncompressed (already required) but this seems like a
separable issue, since it's mostly in service of optimization rather than
simplicity.

What do people think?
-Ekr





_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls

Gmane