Internet Engineering Task Force (IETF) B. Moeller
Request for Comments: 7507 A. Langley
Updates: 2246, 4346, 4347, 5246, 6347 Google
Category: Standards Track April 2015
ISSN: 2070-1721
Internet Engineering Task Force (IETF) B. Moeller
Request for Comments: 7507 A. Langley
Updates: 2246, 4346, 4347, 5246, 6347 Google
Category: Standards Track April 2015
ISSN: 2070-1721
TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks
用于防止协议降级攻击的TLS回退信令密码套件值（SCSV）
Abstract
摘要
This document defines a Signaling Cipher Suite Value (SCSV) that prevents protocol downgrade attacks on the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. It updates RFCs 2246, 4346, 4347, 5246, and 6347. Server update considerations are included.
本文档定义了一个信令密码套件值（SCSV），用于防止对传输层安全性（TLS）和数据报传输层安全性（DTLS）协议的协议降级攻击。它更新了RFCs 2246、4346、4347、5246和6347。包括服务器更新注意事项。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7507.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Protocol Values . . . . . . . . . . . . . . . . . . . . . . . 3
3. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 4
4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 4
5. Operational Considerations . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Protocol Values . . . . . . . . . . . . . . . . . . . . . . . 3
3. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 4
4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 4
5. Operational Considerations . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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, Secure Socket Layer (SSL) 3.0) as the highest supported version.
为了解决遗留服务器的互操作性问题，许多TLS客户机实现不单独依赖TLS协议版本协商机制，而是在初始握手尝试失败时，有意使用降级协议重新连接。这类客户端可能会退回到它们宣布TLS 1.0（甚至其前身，安全套接字层（SSL）3.0）版本为最高支持版本的连接。
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 harmful when the result is loss of the TLS extension feature by downgrading to SSL 3.0. This document defines an SCSV that can be employed to prevent unintended protocol downgrades between clients and servers that comply with 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.)
所有不必要的协议降级都是不可取的（例如，如果客户端和服务器都支持TLS 1.2，则从TLS 1.2降级到TLS 1.1）；当结果是通过降级到SSL 3.0而丢失TLS扩展功能时，它们可能特别有害。本文档定义了一个SCSV，该SCSV可用于防止符合本文档要求的客户端和服务器之间发生意外协议降级，方法是让客户端指示当前连接尝试仅为回退，并让服务器在检测到不适当的回退时返回致命警报。（该警报不一定表示故意降级攻击，因为网络故障也可能导致不适当的回退重试。）
The fallback SCSV defined in this document is not a suitable substitute for proper TLS version negotiation. TLS implementations need to properly handle TLS version negotiation and extensibility mechanisms to avoid the security issues and connection delays associated with fallback retries.
本文件中定义的备用SCSV不适合替代适当的TLS版本协商。TLS实现需要正确处理TLS版本协商和扩展机制，以避免与回退重试相关的安全问题和连接延迟。
This specification applies to implementations of TLS 1.0 [RFC2246], 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 relevant if the TLS implementations also include support for predecessor protocol SSL 3.0 [RFC6101].) It can be applied similarly to later protocol versions.
本规范适用于TLS 1.0[RFC2246]、TLS 1.1[RFC4346]和TLS 1.2[RFC5246]的实现，以及DTLS 1.0[RFC4347]和DTLS 1.2[RFC6347]的实现。（如果TLS实现还包括对前代协议SSL 3.0[RFC6101]的支持，则这一点尤为重要）。它可以类似地应用于更高版本的协议。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document defines a new TLS cipher suite value:
本文档定义了一个新的TLS密码套件值：
TLS_FALLBACK_SCSV {0x56, 0x00}
TLS_回退_SCSV{0x56，0x00}
This is an 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.
这是一个SCSV，也就是说，它实际上并不对应于一套密码系统，服务器在握手时永远无法选择它；相反，它在客户机Hello消息中的存在充当从客户机到服务器的向后兼容信号。
This document also allocates a new alert value in the TLS Alert Registry [RFC5246]:
本文档还将在TLS警报注册表[RFC5246]中分配新警报值：
enum {
/* ... */
inappropriate_fallback(86),
/* ... */
(255)
} AlertDescription;
enum {
/* ... */
inappropriate_fallback(86),
/* ... */
(255)
} AlertDescription;
This alert is only generated by servers, as described in Section 3. It is always fatal.
此警报仅由服务器生成，如第3节所述。它总是致命的。
This section specifies server behavior when receiving the TLS_FALLBACK_SCSV cipher suite from a client in ClientHello.cipher_suites.
本节指定从ClientHello.cipher_suites中的客户端接收TLS_FALLBACK_SCSV密码套件时的服务器行为。
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 (unless it responds with a fatal protocol_version alert because the version indicated in ClientHello.client_version is unsupported). The record layer version number for this alert MUST be set to either ClientHello.client_version (as it would for the Server Hello message if the server was continuing the handshake) or to the record layer version number used by the client.
o 如果ClientHello.cipher_套件中出现TLS_FALLBACK_SCSV，并且服务器支持的最高协议版本高于ClientHello.client_版本中指示的版本，则服务器必须以致命的不适当_FALLBACK警报进行响应（除非它响应致命的协议\u版本警报，因为不支持ClientHello.client\u版本中指示的版本）。此警报的记录层版本号必须设置为ClientHello.client\u版本（如果服务器继续握手，则服务器Hello消息的版本号相同）或客户端使用的记录层版本号。
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.
o 否则（要么TLS_FALLBACK_SCSV没有出现，要么它出现并且客户端的协议版本至少是服务器支持的最高协议版本），服务器照常进行握手。
(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 inappropriate_fallback alert.)
（如果服务器响应适当的客户端Hello消息将其用于ServerHello.server_版本，则服务器支持协议版本。如果实现了特定的协议版本，但服务器设置完全禁用了该版本，则认为不支持该版本。例如，如果实现的最高协议版本为TLS1.2但服务器运营商已禁用此版本，TLS 1.1客户端Hello with TLS_FALLBACK_SCSV不保证响应不适当的_FALLBACK警报。）
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.
TLS_FALLBACK_SCSV cipher suite值用于使用降级协议重复连接尝试（执行“回退重试”）的客户端，以解决与旧服务器的互操作性问题。
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; see Section 6 for security considerations for this recommendation. (The client SHOULD put TLS_FALLBACK_SCSV after all cipher suites that it actually intends to negotiate.)
o 如果客户端发送的ClientHello.client\u版本包含的值低于客户端支持的最新（最高值）版本，则应在ClientHello.cipher\u套件中包含TLS\u回退\u SCSV密码套件值；有关本建议的安全注意事项，请参见第6节。（客户应将TLS_FALLBACK_SCSV放在其实际打算协商的所有密码套件之后。）
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 Appendix E.1 of [RFC5246].)
o 作为上述情况的例外，当客户端打算恢复会话并将ClientHello.client_版本设置为该会话协商的协议版本时，它不得在ClientHello.cipher_套件中包含TLS_FALLBACK_SCSV。（在这种情况下，假设客户机已经知道服务器支持的最高协议版本：参见[RFC5246]的附录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.
o 如果客户端将ClientHello.client_版本设置为其支持的最高协议版本，则它不得在ClientHello.cipher_套件中包含TLS_FALLBACK_SCSV。
(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.)
（如果客户端通常尝试在握手中使用协议版本，则客户端支持该版本。如果实现了特定协议版本，但客户端设置完全禁用了该版本，则认为不支持该版本。例如，如果实现的最高协议版本为TLS 1.2，但用户禁用了该版本，则TLS 1。预计会有1次握手，但不保证发送TLS\U回退\U SCSV。）
Fallback retries could be caused by events such as network glitches, and a client including TLS_FALLBACK_SCSV in ClientHello.cipher_suites may receive an inappropriate_fallback alert in response, indicating that the server supports a higher protocol version. Thus, if a client intends to use retries to work around network glitches, it should then retry with the highest version it supports.
回退重试可能是由网络故障等事件引起的，客户端（包括ClientHello.cipher_套件中的TLS_Fallback_SCSV）可能会收到不适当的回退警报作为响应，表明服务器支持更高的协议版本。因此，如果客户机打算使用重试来解决网络故障，则应使用其支持的最高版本重试。
If a client keeps track of the highest protocol version apparently supported by a particular server for use in 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 timeout since the server's highest protocol version could change over time.)
如果客户端跟踪特定服务器明显支持的最高协议版本，以便在以后的ClientHello.client_版本中使用，则如果客户端从该服务器收到不适当的_回退警报，则必须清除存储的最高支持协议版本。（在没有警报的情况下，客户端在超时后清除该状态是一个好主意，但超出了本文的范围，因为服务器的最高协议版本可能会随着时间的推移而改变。）
For clients that use client-side TLS False Start [false-start], it is important to note that the TLS_FALLBACK_SCSV mechanism cannot protect the first round of application data sent by the client: refer to the Security Considerations (Section 6) of [false-start].
对于使用客户端TLS False Start[False Start]的客户端，必须注意TLS_FALLBACK_SCSV机制无法保护客户端发送的第一轮应用程序数据：请参阅[False Start]的安全注意事项（第6节）。
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.
如果旧服务器实现不“版本容忍”（无法正确处理新协议版本的客户端Hello消息），则更新旧服务器群集以同时添加对新协议版本的支持和对TLS_FALLBACK_SCSV的支持可能会带来复杂问题：更新的服务器节点可能会拒绝与旧服务器节点进行互操作所需的回退重试。
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); then, after all legacy (version-intolerant) implementations have been removed, change server settings to allow new protocol versions.
通过两个连续步骤更新服务器集群可以确保安全：首先，更新服务器软件，但保持支持的最高版本不变（通过在服务器设置中禁用较新版本）；然后，在删除所有遗留（版本不可容忍）实现后，更改服务器设置以允许新的协议版本。
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. It is important to remember that omitting TLS_FALLBACK_SCSV enables downgrade attacks, so implementors must take into account whether the protocol version given by ClientHello.client_version still provides an acceptable level of protection. 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 preferable to potentially not being able to connect at all: so TLS_FALLBACK_SCSV could be omitted for this particular protocol downgrade step.
第4节不要求客户机实现在任何特定情况下发送TLS_FALLBACK_SCSV，它只是建议这样做；可以根据客户的安全需求调整行为。重要的是要记住，省略TLS_FALLBACK_SCSV会导致降级攻击，因此实施者必须考虑ClientHello.client_版本提供的协议版本是否仍然提供可接受的保护级别。例如，在新协议版本的初始部署期间（可能会出现一些互操作性问题），在出现问题的情况下，平稳地返回到以前的协议版本可能比根本无法连接更好：因此，对于这个特定的协议降级步骤，可以省略TLS_FALLBACK_SCSV。
However, it is strongly recommended to send TLS_FALLBACK_SCSV when downgrading to SSL 3.0 as the Cipher Block Chaining (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.
但是，强烈建议在降级到SSL 3.0时发送TLS_FALLBACK_SCSV，因为SSL 3.0中的密码块链接（CBC）密码套件存在无法通过实施解决方案解决的弱点，如后续（TLS）协议版本中的其余弱点。
IANA has added TLS cipher suite number 0x56,0x00 with the name TLS_FALLBACK_SCSV to the TLS Cipher Suite Registry and alert number 86 with the name inappropriate_fallback to the TLS Alert Registry, as shown below. The registries are available from <http://www.iana.org/assignments/tls-parameters>.
IANA已将名为TLS_FALLBACK_SCSV的TLS密码套件编号0x56,0x00添加到TLS密码套件注册表中，并将名为unposite_FALLBACK的警报编号86添加到TLS警报注册表中，如下所示。登记处可从以下网址获得：<http://www.iana.org/assignments/tls-parameters>.
+-----------+-------------------+---------+-----------+
| Value | Description | DTLS-OK | Reference |
+-----------+-------------------+---------+-----------+
| 0x56,0x00 | TLS_FALLBACK_SCSV | Y | RFC 7507 |
+-----------+-------------------+---------+-----------+
+-----------+-------------------+---------+-----------+
| Value | Description | DTLS-OK | Reference |
+-----------+-------------------+---------+-----------+
| 0x56,0x00 | TLS_FALLBACK_SCSV | Y | RFC 7507 |
+-----------+-------------------+---------+-----------+
Addition to the TLS Cipher Suite Registry
添加到TLS密码套件注册表
+-------+------------------------+---------+-----------+
| Value | Description | DTLS-OK | Reference |
+-------+------------------------+---------+-----------+
| 86 | inappropriate_fallback | Y | RFC 7507 |
+-------+------------------------+---------+-----------+
+-------+------------------------+---------+-----------+
| Value | Description | DTLS-OK | Reference |
+-------+------------------------+---------+-----------+
| 86 | inappropriate_fallback | Y | RFC 7507 |
+-------+------------------------+---------+-----------+
Addition to the TLS Alert Registry
添加到TLS警报注册表
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999, <http://www.rfc-editor.org/info/rfc2246>.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月<http://www.rfc-editor.org/info/rfc2246>.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006, <http://www.rfc-editor.org/info/rfc4346>.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月<http://www.rfc-editor.org/info/rfc4346>.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006, <http://www.rfc-editor.org/info/rfc4347>.
[RFC4347]Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，2006年4月<http://www.rfc-editor.org/info/rfc4347>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，2012年1月<http://www.rfc-editor.org/info/rfc6347>.
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, August 2011, <http://www.rfc-editor.org/info/rfc6101>.
[RFC6101]Freier，A.，Karlton，P.，和P.Kocher，“安全套接字层（SSL）协议版本3.0”，RFC 61012011年8月<http://www.rfc-editor.org/info/rfc6101>.
[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.
[错误启动]Langley，A.，Modadugu，N.，和B.Moeller，“传输层安全（TLS）错误启动”，正在进行的工作，草稿-bmoeller-TLS-falsestart-01，2014年11月。
Acknowledgements
致谢
This specification was inspired by an earlier proposal by Eric Rescorla. We also thank Daniel Kahn Gillmor, Joe Saloway, Brian Smith, Martin Thomson, and others in the TLS Working Group for their feedback and suggestions.
本规范的灵感来自Eric Rescorla的早期提案。我们还感谢Daniel Kahn Gillmor、Joe Saloway、Brian Smith、Martin Thomson和TLS工作组中的其他人的反馈和建议。
Authors' Addresses
作者地址
Bodo Moeller Google Switzerland GmbH Brandschenkestrasse 110 Zurich 8002 Switzerland
Bodo Moeller谷歌瑞士有限公司Brandschenkestrase 110苏黎世8002瑞士
EMail: bmoeller@acm.org
EMail: bmoeller@acm.org
Adam Langley Google Inc. 345 Spear St San Francisco, CA 94105 United States
亚当兰利谷歌公司345矛旧金山ST，CA 94105美国
EMail: agl@google.com
EMail: agl@google.com