draft-ietf-tls-downgrade-scsv-05.txt   rfc7507.txt 
Network Working Group B. Moeller Internet Engineering Task Force (IETF) B. Moeller
Internet-Draft A. Langley Request for Comments: 7507 A. Langley
Updates: 2246, 4346, 4347, 5246, 6347 Google Updates: 2246, 4346, 4347, 5246, 6347 Google
(if approved) February 20, 2015 Category: Standards Track April 2015
Intended status: Standards Track ISSN: 2070-1721
Expires: August 24, 2015
TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol TLS Fallback Signaling Cipher Suite Value (SCSV)
Downgrade Attacks for Preventing Protocol Downgrade Attacks
draft-ietf-tls-downgrade-scsv-05
Abstract Abstract
This document defines a Signaling Cipher Suite Value (SCSV) that This document defines a Signaling Cipher Suite Value (SCSV) that
prevents protocol downgrade attacks on the Transport Layer Security prevents protocol downgrade attacks on the Transport Layer Security
(TLS) and Datagram Transport Layer Security (DTLS) protocols. It (TLS) and Datagram Transport Layer Security (DTLS) protocols. It
updates RFC 2246, RFC 4346, RFC 4347, RFC 5246, and RFC 6347. Server updates RFCs 2246, 4346, 4347, 5246, and 6347. Server update
update considerations are included. considerations are included.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on August 24, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7507.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Protocol values . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Values . . . . . . . . . . . . . . . . . . . . . . . 3
3. Server behavior . . . . . . . . . . . . . . . . . . . . . . . 3 3. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 4
4. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 4 4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 4
5. Operational Considerations . . . . . . . . . . . . . . . . . 5 5. Operational Considerations . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
To work around interoperability problems with legacy servers, many To work around interoperability problems with legacy servers, many
TLS client implementations do not rely on the TLS protocol version TLS client implementations do not rely on the TLS protocol version
negotiation mechanism alone, but will intentionally reconnect using a negotiation mechanism alone but will intentionally reconnect using a
downgraded protocol if initial handshake attempts fail. Such clients downgraded protocol if initial handshake attempts fail. Such clients
may fall back to connections in which they announce a version as low 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 as TLS 1.0 (or even its predecessor, Secure Socket Layer (SSL) 3.0)
supported version. as the highest supported version.
While such fallback retries can be a useful last resort for While such fallback retries can be a useful last resort for
connections to actual legacy servers, there's a risk that active connections to actual legacy servers, there's a risk that active
attackers could exploit the downgrade strategy to weaken the attackers could exploit the downgrade strategy to weaken the
cryptographic security of connections. Also, handshake errors due to cryptographic security of connections. Also, handshake errors due to
network glitches could similarly be misinterpreted as interaction network glitches could similarly be misinterpreted as interaction
with a legacy server and result in a protocol downgrade. with a legacy server and result in a protocol downgrade.
All unnecessary protocol downgrades are undesirable (e.g., from TLS 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 1.2 to TLS 1.1, if both the client and the server actually do support
TLS 1.2); they can be particularly harmful when the result is loss of TLS 1.2); they can be particularly harmful when the result is loss of
the TLS extension feature by downgrading to SSL 3.0. This document the TLS extension feature by downgrading to SSL 3.0. This document
defines a Signaling Cipher Suite Value (SCSV) that can be employed to defines an SCSV that can be employed to prevent unintended protocol
prevent unintended protocol downgrades between clients and servers downgrades between clients and servers that comply with this document
that comply with this document, by having the client indicate that by having the client indicate that the current connection attempt is
the current connection attempt is merely a fallback, and by having merely a fallback and by having the server return a fatal alert if it
the server return a fatal alert if it detects an inappropriate detects an inappropriate fallback. (The alert does not necessarily
fallback. (The alert does not necessarily indicate an intentional indicate an intentional downgrade attack, since network glitches too
downgrade attack, since network glitches too could result in could result in inappropriate fallback retries.)
inappropriate fallback retries.)
The fallback SCSV defined in this document is not a suitable The fallback SCSV defined in this document is not a suitable
substitute for proper TLS version negotiation. TLS implementations substitute for proper TLS version negotiation. TLS implementations
need to properly handle TLS version negotiation and extensibility need to properly handle TLS version negotiation and extensibility
mechanisms to avoid the security issues and connection delays mechanisms to avoid the security issues and connection delays
associated with fallback retries. associated with fallback retries.
This specification applies to implementations of TLS 1.0 [RFC2246], This specification applies to implementations of TLS 1.0 [RFC2246],
TLS 1.1 [RFC4346], and TLS 1.2 [RFC5246], and to implementations of TLS 1.1 [RFC4346], and TLS 1.2 [RFC5246], and to implementations of
DTLS 1.0 [RFC4347] and DTLS 1.2 [RFC6347]. (It is particularly DTLS 1.0 [RFC4347] and DTLS 1.2 [RFC6347]. (It is particularly
relevant if the TLS implementations also include support for relevant if the TLS implementations also include support for
predecessor protocol SSL 3.0 [RFC6101].) It can be applied similarly predecessor protocol SSL 3.0 [RFC6101].) It can be applied similarly
to later protocol versions. to later protocol versions.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Protocol values 2. Protocol Values
This document defines a new TLS cipher suite value: This document defines a new TLS cipher suite value:
TLS_FALLBACK_SCSV {0x56, 0x00} TLS_FALLBACK_SCSV {0x56, 0x00}
This is a signaling cipher suite value (SCSV), i.e., it does not This is an SCSV, i.e., it does not actually correspond to a suite of
actually correspond to a suite of cryptosystems, and it can never be cryptosystems, and it can never be selected by the server in the
selected by the server in the handshake; rather, its presence in the handshake; rather, its presence in the Client Hello message serves as
Client Hello message serves as a backwards-compatible signal from the a backwards-compatible signal from the client to the server.
client to the server.
This document also allocates a new alert value in the TLS Alert This document also allocates a new alert value in the TLS Alert
Registry [RFC5246]: Registry [RFC5246]:
enum { enum {
/* ... */ /* ... */
inappropriate_fallback(86), inappropriate_fallback(86),
/* ... */ /* ... */
(255) (255)
} AlertDescription; } AlertDescription;
This alert is only generated by servers, as described in Section 3. This alert is only generated by servers, as described in Section 3.
It is always fatal. It is always fatal.
3. Server behavior 3. Server Behavior
This section specifies server behavior when receiving the This section specifies server behavior when receiving the
TLS_FALLBACK_SCSV cipher suite from a client in TLS_FALLBACK_SCSV cipher suite from a client in
ClientHello.cipher_suites. ClientHello.cipher_suites.
o If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the o If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the
highest protocol version supported by the server is higher than highest protocol version supported by the server is higher than
the version indicated in ClientHello.client_version, the server the version indicated in ClientHello.client_version, the server
MUST respond with a fatal inappropriate_fallback alert (unless it MUST respond with a fatal inappropriate_fallback alert (unless it
responds with a fatal protocol_version alert because the version responds with a fatal protocol_version alert because the version
indicated in ClientHello.client_version is unsupported). The indicated in ClientHello.client_version is unsupported). The
record layer version number for this alert MUST be set to either record layer version number for this alert MUST be set to either
ClientHello.client_version (as it would for the Server Hello ClientHello.client_version (as it would for the Server Hello
message if the server was continuing the handshake), or to the message if the server was continuing the handshake) or to the
record layer version number used by the client. record layer version number used by the client.
o Otherwise (either TLS_FALLBACK_SCSV does not appear, or it appears o Otherwise (either TLS_FALLBACK_SCSV does not appear or it appears
and the client's protocol version is at least the highest protocol and the client's protocol version is at least the highest protocol
version supported by the server), the server proceeds with the version supported by the server), the server proceeds with the
handshake as usual. handshake as usual.
(A protocol version is supported by the server if, in response to (A protocol version is supported by the server if, in response to
appropriate Client Hello messages, the server would use it for appropriate Client Hello messages, the server would use it for
ServerHello.server_version. If a particular protocol version is ServerHello.server_version. If a particular protocol version is
implemented but completely disabled by server settings, it is not implemented but completely disabled by server settings, it is not
considered supported. For example, if the implementation's highest considered supported. For example, if the implementation's highest
protocol version is TLS 1.2 but the server operator has disabled this 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 version, a TLS 1.1 Client Hello with TLS_FALLBACK_SCSV does not
warrant responding with an inappropriate_fallback alert.) warrant responding with an inappropriate_fallback alert.)
4. Client behavior 4. Client Behavior
The TLS_FALLBACK_SCSV cipher suite value is meant for use by clients The TLS_FALLBACK_SCSV cipher suite value is meant for use by clients
that repeat a connection attempt with a downgraded protocol (perform that repeat a connection attempt with a downgraded protocol (perform
a "fallback retry") in order to work around interoperability problems a "fallback retry") in order to work around interoperability problems
with legacy servers. with legacy servers.
o If a client sends a ClientHello.client_version containing a lower o If a client sends a ClientHello.client_version containing a lower
value than the latest (highest-valued) version supported by the value than the latest (highest-valued) version supported by the
client, it SHOULD include the TLS_FALLBACK_SCSV cipher suite value client, it SHOULD include the TLS_FALLBACK_SCSV cipher suite value
in ClientHello.cipher_suites; see Section 6 for security in ClientHello.cipher_suites; see Section 6 for security
considerations for this recommendation. (The client SHOULD put considerations for this recommendation. (The client SHOULD put
TLS_FALLBACK_SCSV after all cipher suites that it actually intends TLS_FALLBACK_SCSV after all cipher suites that it actually intends
to negotiate.) to negotiate.)
o As an exception to the above, when a client intends to resume a o As an exception to the above, when a client intends to resume a
session and sets ClientHello.client_version to the protocol session and sets ClientHello.client_version to the protocol
version negotiated for that session, it MUST NOT include version negotiated for that session, it MUST NOT include
TLS_FALLBACK_SCSV in ClientHello.cipher_suites. (In this case, it TLS_FALLBACK_SCSV in ClientHello.cipher_suites. (In this case, it
is assumed that the client already knows the highest protocol is assumed that the client already knows the highest protocol
version supported by the server: see [RFC5246], Appendix E.1.) version supported by the server: see Appendix E.1 of [RFC5246].)
o If a client sets ClientHello.client_version to its highest o If a client sets ClientHello.client_version to its highest
supported protocol version, it MUST NOT include TLS_FALLBACK_SCSV supported protocol version, it MUST NOT include TLS_FALLBACK_SCSV
in ClientHello.cipher_suites. in ClientHello.cipher_suites.
(A protocol version is supported by the client if the client normally (A protocol version is supported by the client if the client normally
attempts to use it in handshakes. If a particular protocol version attempts to use it in handshakes. If a particular protocol version
is implemented but completely disabled by client settings, it is not is implemented but completely disabled by client settings, it is not
considered supported. For example, if the implementation's highest considered supported. For example, if the implementation's highest
protocol version is TLS 1.2 but the user has disabled this version, a protocol version is TLS 1.2 but the user has disabled this version, a
skipping to change at page 5, line 30 skipping to change at page 5, line 37
that the server supports a higher protocol version. Thus, if a that the server supports a higher protocol version. Thus, if a
client intends to use retries to work around network glitches, it client intends to use retries to work around network glitches, it
should then retry with the highest version it supports. should then retry with the highest version it supports.
If a client keeps track of the highest protocol version apparently If a client keeps track of the highest protocol version apparently
supported by a particular server for use in supported by a particular server for use in
ClientHello.client_version later, then if the client receives an ClientHello.client_version later, then if the client receives an
inappropriate_fallback alert from that server, it MUST clear the inappropriate_fallback alert from that server, it MUST clear the
memorized highest supported protocol version. (Without the alert, it memorized highest supported protocol version. (Without the alert, it
is a good idea -- but outside of the scope of this document -- for 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 clients to clear that state after a timeout since the server's
highest protocol version could change over time.) highest protocol version could change over time.)
For clients that use client-side TLS False Start [false-start], it is For clients that use client-side TLS False Start [false-start], it is
important to note that the TLS_FALLBACK_SCSV mechanism cannot protect important to note that the TLS_FALLBACK_SCSV mechanism cannot protect
the first round of application data sent by the client: refer to the the first round of application data sent by the client: refer to the
Security Considerations in [false-start], Section 6. Security Considerations (Section 6) of [false-start].
5. Operational Considerations 5. Operational Considerations
Updating legacy server clusters to simultaneously add support for Updating legacy server clusters to simultaneously add support for
newer protocol versions and support for TLS_FALLBACK_SCSV can have newer protocol versions and support for TLS_FALLBACK_SCSV can have
complications, if the legacy server implementation is not "version- complications if the legacy server implementation is not "version-
tolerant" (cannot properly handle Client Hello messages for newer tolerant" (cannot properly handle Client Hello messages for newer
protocol versions): fallback retries required for interoperability protocol versions): fallback retries required for interoperability
with old server nodes might be rejected by updated server nodes. with old server nodes might be rejected by updated server nodes.
Updating the server cluster in two consecutive steps makes this safe: Updating the server cluster in two consecutive steps makes this safe:
first, update the server software but leave the highest supported first, update the server software but leave the highest supported
version unchanged (by disabling newer versions in server settings); version unchanged (by disabling newer versions in server settings);
then, after all legacy (version-intolerant) implementations have been then, after all legacy (version-intolerant) implementations have been
removed, change server settings to allow new protocol versions. removed, change server settings to allow new protocol versions.
skipping to change at page 6, line 21 skipping to change at page 6, line 27
downgrade attacks, so implementors must take into account whether the downgrade attacks, so implementors must take into account whether the
protocol version given by ClientHello.client_version still provides protocol version given by ClientHello.client_version still provides
an acceptable level of protection. For example, during the initial an acceptable level of protection. For example, during the initial
deployment of a new protocol version (when some interoperability deployment of a new protocol version (when some interoperability
problems may have to be expected), smoothly falling back to the problems may have to be expected), smoothly falling back to the
previous protocol version in case of problems may be preferable to previous protocol version in case of problems may be preferable to
potentially not being able to connect at all: so TLS_FALLBACK_SCSV potentially not being able to connect at all: so TLS_FALLBACK_SCSV
could be omitted for this particular protocol downgrade step. could be omitted for this particular protocol downgrade step.
However, it is strongly recommended to send TLS_FALLBACK_SCSV when 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 downgrading to SSL 3.0 as the Cipher Block Chaining (CBC) cipher
weaknesses that cannot be addressed by implementation workarounds suites in SSL 3.0 have weaknesses that cannot be addressed by
like the remaining weaknesses in later (TLS) protocol versions. implementation workarounds like the remaining weaknesses in later
(TLS) protocol versions.
7. IANA Considerations 7. IANA Considerations
[[ TO BE REMOVED: The requested registry allocations require IANA has added TLS cipher suite number 0x56,0x00 with the name
Standards Action, i.e., will only be official with the IESG's TLS_FALLBACK_SCSV to the TLS Cipher Suite Registry and alert number
Standards Track RFC approval. Since this document is currently an 86 with the name inappropriate_fallback to the TLS Alert Registry, as
Internet-Draft, IANA so far has in fact not added the cipher suite shown below. The registries are available from
number and alert number to the respective registries. The values as <http://www.iana.org/assignments/tls-parameters>.
shown are used in early implementations. ]]
+-----------+-------------------+---------+-----------------+
| Value | Description | DTLS-OK | Reference |
+-----------+-------------------+---------+-----------------+
| 0x56,0x00 | TLS_FALLBACK_SCSV | Y | (this document) |
+-----------+-------------------+---------+-----------------+
http://www.iana.org/assignments/tls-parameters +-----------+-------------------+---------+-----------+
| Value | Description | DTLS-OK | Reference |
+-----------+-------------------+---------+-----------+
| 0x56,0x00 | TLS_FALLBACK_SCSV | Y | RFC 7507 |
+-----------+-------------------+---------+-----------+
+-------+------------------------+---------+-----------------+ Addition to the TLS Cipher Suite Registry
| Value | Description | DTLS-OK | Reference |
+-------+------------------------+---------+-----------------+
| 86 | inappropriate_fallback | Y | (this document) |
+-------+------------------------+---------+-----------------+
http://www.iana.org/assignments/tls-parameters +-------+------------------------+---------+-----------+
| Value | Description | DTLS-OK | Reference |
+-------+------------------------+---------+-----------+
| 86 | inappropriate_fallback | Y | RFC 7507 |
+-------+------------------------+---------+-----------+
IANA has added TLS cipher suite number 0x56,0x00 with name Addition to the TLS Alert Registry
TLS_FALLBACK_SCSV to the TLS Cipher Suite registry, and alert number
86 with name inappropriate_fallback to the TLS Alert registry.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999,
<http://www.rfc-editor.org/info/rfc2246>.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006,
<http://www.rfc-editor.org/info/rfc4346>.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006,
<http://www.rfc-editor.org/info/rfc4347>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012,
<http://www.rfc-editor.org/info/rfc6347>.
8.2. Informative References 8.2. Informative References
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure
Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
August 2011. August 2011, <http://www.rfc-editor.org/info/rfc6101>.
[false-start] [false-start]
Langley, A., Modadugu, N., and B. Moeller, "Transport Langley, A., Modadugu, N., and B. Moeller, "Transport
Layer Security (TLS) False Start", Work in Progress, Layer Security (TLS) False Start", Work in Progress,
draft-bmoeller-tls-falsestart-01, November 2014. draft-bmoeller-tls-falsestart-01, November 2014.
Appendix A. Acknowledgements Acknowledgements
This specification was inspired by an earlier proposal by Eric This specification was inspired by an earlier proposal by Eric
Rescorla. We also thank Daniel Kahn Gillmor, Joe Saloway, Brian Rescorla. We also thank Daniel Kahn Gillmor, Joe Saloway, Brian
Smith, Martin Thomson, and others in the TLS Working Group for their Smith, Martin Thomson, and others in the TLS Working Group for their
feedback and suggestions. feedback and suggestions.
Authors' Addresses Authors' Addresses
Bodo Moeller Bodo Moeller
Google Switzerland GmbH Google Switzerland GmbH
Brandschenkestrasse 110 Brandschenkestrasse 110
Zurich 8002 Zurich 8002
Switzerland Switzerland
Email: bmoeller@acm.org EMail: bmoeller@acm.org
Adam Langley Adam Langley
Google Inc. Google Inc.
345 Spear St 345 Spear St
San Francisco, CA 94105 San Francisco, CA 94105
USA United States
Email: agl@google.com EMail: agl@google.com
 End of changes. 41 change blocks. 
88 lines changed or deleted 84 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/