TLS标准化的演进与启示

TLS的被动与主动标准化

1 引言

传输层安全（TLS）协议每天被数百万甚至数十亿用户使用，是保护万维网通信事实上的标准。该协议最初由网景通信公司以安全套接层（SSL）的名称开发，随后于20世纪90年代中期正式由互联网工程任务组（IETF）接管，并最终在1999年发布了TLS 1.0[32]。后续版本分别于2006年（TLS 1.1,[33]）和 2008年（TLS 1.2,[34]）发布。自那时起，TLS受到了安全性研究社区越来越多的关注。已有数十篇关于TLS的研究论文发表，其中包含了对该协议的正面和负面评价。原本只是零星发表的论文，在过去五年中已形成井喷之势。可以说，研究社区对此兴趣激增的主要触发因素是雷和雷克斯在2009年发现的TLS重新协商漏洞，以及2011年和2012年出现的BEAST和CRIME攻击。

在TLS 1.2及更早版本中发现的众多弱点，以及对提高协议效率（通过降低建立初始安全连接时的延迟）日益增长的压力，促使互联网工程任务组于 2014年春季开始起草该协议的下一个版本TLS 1.3。与早期版本所采用的开发流程不同，TLS工作组采用了“先分析后部署”的设计理念，并积极努力地推动相关方参与研究社区试图在协议最终确定之前发现并修复漏洞。

鉴于传输层安全协议（TLS）的重要性、互联网工程任务组（IETF）在 TLS 1.3设计方法论上的近期转变，以及TLS 1.3现已进入标准化过程的尾声，我们认为有必要讲述TLS标准化的历程。在TLS 1.3标准化之前，TLS工作组（TLS WG）遵循的是被动响应式的标准化过程：攻击被披露后，工作组通过更新协议的下一个版本或发布TLS标准的补丁来应对这些攻击。多种因素促成了这种标准化过程的采用。正如我们接下来所论述的，在协议设计时期，协议分析工具尚不成熟，研究社区对标准化过程的参与极为有限，而且直到2009年至2012年的第一波攻击出现之前，TLS攻击并未被认为具有足够的实际影响，因而无需紧急修改。相比之下，当前TLS 1.3的标准化过程则高度主动。我们主张，更加成熟的分析工具的可用性、实际攻击的威胁、积极参与的研究社区的存在，以及与该社区更为开放的对话，共同促成了TLS标准化过程的这一转变。

这种较新的流程可以说取得了成功；一些研究工作有助于增强对传输层安全协议设计的信心[12,35,36,42,57,64],，其他研究则及时发现了缺陷[18,31]。该协议的设计本身也受到了研究社区的显著影响[61],，并且实现传输层安全协议与分析传输层安全协议的人员之间的沟通可能从未如此充分。

尽管取得了相对成功，我们仍认为有必要反思TLS 1.3的标准化过程是否还有改进空间，以及它在多大程度上适用于更广泛的标准化领域。为此，我们简要考察了不同标准化机构所采用的标准化模型，并通过TLS的视角分析它们之间的差异、优缺点。具体而言，我们聚焦于互联网工程任务组（IETF）、国际标准化组织（ISO）以及美国国家标准与技术研究院（NIST）。我们开展了一项思想实验，旨在确定哪种标准化模型最适合TLS这类协议。

1.1 贡献

本文详细阐述了传输层安全协议的标准化过程，并对互联网工程任务组近期采用的设计方法论转变进行了评述。我们考察了部署后分析时代，即互联网工程任务组对协议漏洞作出反应的时期；同时也考察了部署前分析时代，即互联网工程任务组积极尝试预防协议弱点的时期。我们的贡献如下：

部署前与部署后分析。 我们对传输层安全协议标准化过程进行了描述，分析了可能导致其发展的各种因素分别用于 TLS 1.2 及以下版本和 TLS 1.3 的不同标准化周期。我们对可用于分析的工具、学术界的参与程度，以及推动标准化过程中各参与方的激励机制进行了评述。

进一步改进。 我们评论了TLS 1.3的标准化过程可能如何改进，并提出了一个针对安全协议的替代标准化周期。

比较分析。 我们对标准化模型进行了比较分析，并通过考察这些模型在传输层安全协议等关键协议标准化中的适用性，讨论了它们的优点和缺点。

1.2 相关工作

在关于标准化透明度的研究中，格里芬 [49]提出了万花筒会议的案例研究，详细描述了国际电信联盟（ITU）为举办一场学术会议所采取的行动，旨在促进标准开发中的开放性，并将学术界培育为新技术和新思想的重要外部来源。我们探讨了会议和研讨会作为加强学术界参与的手段，但也表明在TLS 1.3的案例中，学术界在标准化过程中充当了内部思想来源。

古特曼等讨论了在[50],另一个我们涉及的主题中为安全性协议设定要求的重要性。但他们似乎是在事后分析的背景下进行的，因为他们讨论了在已发布标准中发现缺陷后，用于更新要求的形式化技术。

我们不知道有任何工作涵盖了完整的传输层安全协议标准化过程。

1.3 论文结构

在第2节中，我们简要介绍传输层安全协议和互联网工程任务组的背景。在第3节中，我们讨论TLS 1.2及更早版本的标准化过程。在第4节中，我们介绍了TLS 1.3所遵循的标准化过程。在第5节中，我们探讨了互联网工程任务组范围之外的协议标准化，并在第6节中进行总结。

2 背景

2.1 传输层安全 协议

我们对TLS协议进行了高层次的概述，仅描述了与后续标准化讨论相关的内容。更多详细信息请参阅[34,78]。

传输层安全协议是一种网络协议，旨在为运行在应用层的协议提供安全性服务。TLS的主要目标是促进两个通信实体（即客户端和服务器）之间建立安全通道。TLS协议由多个子协议组成，其中最重要的两个是握手协议和记录协议。握手协议协商所有与密码学相关的参数（包括使用的TLS版本、认证方式和密钥交换方法，以及后续将使用的对称密钥算法）。它对一个或两个通信实体进行认证，并为记录协议中用于保护应用数据的对称算法生成密钥。例如，如果客户端和服务器在TLS 1.2握手中协商使用TLS_RSA_WITH_AES128_CBC_SHA256密码套件，则服务器将提供一个RSA证书，用于密钥交换和实体认证。在此示例中，记录协议将使用高级加密标准的CBC模式对应用数据进行加密，并使用SHA‐256作为HMAC算法的一部分以提供消息认证码。

TLS 1.2 及更早版本

图1展示了初始 TLS 1.2 握手的消息流程。标有星号的消息是可选的或取决于具体情况，“[…]”类型的花括号表示使用应用流量密钥进行加密。客户端和服务器交换客户端问候和服务器问候 消息，以协商密码套件并交换随机数。通信实体还交换加密参数（服务器密钥交换、客户端密钥交换），这些参数用于派生预主密钥。为实现实体认证，发送证书及相应的验证信息 （证书、证书验证）。通过随机数和预主密钥派生出主密钥，进而用于派生记录协议所使用的应用流量密钥。 完成 消息包含对整个握手过程的消息认证码，确保客户端和服务器对握手过程具有相同视图，并且主动攻击者未篡改任何握手消息。

握手协议在记录协议之上运行，最初使用空加密和MAC算法。更改密码规范消息表示开始使用新协商的加密算法和密钥的意图；它们不被视为握手的一部分，而是属于一个对等协议（即更改密码规范协议）的消息。由于完成消息位于更改密码规范消息之后，因此它们使用握手过程中派生的应用数据流量密钥进行保护。因此，这些消息是作为记录协议的一部分受到保护的第一批消息。随后是现在由记录协议保护的应用数据消息。

初始握手过程中建立的加密参数构成了一个TLS会话。会话可以通过重新协商握手进行更新。这是一种在已建立的TLS会话保护下运行的完整握手。该机制允许更改加密参数（例如）

迪菲‐赫尔曼密钥交换握手)

例如，升级或服务器要求客户端认证。为了避免在重复的握手中进行昂贵的公钥操作，传输层安全协议还提供了一种轻量级的恢复握手，其中新的主密钥从旧的预主密钥和新的随机数派生，从而强制生成新的应用数据密钥。每次这样的恢复握手都会在现有会话内建立一个新的TLS connection；每个会话可以并行存在多个连接。

记录协议（Record Protocol）如前所述，为应用数据（Application Data）以及握手协议（Handshake Protocol）和警报（alert）消息的传输提供了一个安全通道。在 TLS 1.0 和 TLS 1.1 中，该协议采用“先MAC后编码再加密”（MEE）的构造方式，其中 MAC 算法使用多种哈希函数实例化的 HMAC，加密算法则使用分组密码的 CBC 模式或 RC4 流密码（RC4 stream cipher）。序列号（Sequence numbers）被纳入密码学处理过程中，从而形成一个有状态安全通道（stateful secure channel），能够检测 TLS 记录（TLS records）的重放（replays）、删除（deletions）和重新排序（re‐orderings）。TLS 1.2 增加了对带关联数据的认证加密（Authenticated Encryption with Associated Data, AEAD）方案的支持，其中 AES‐GCM 成为越来越受欢迎的选择。

TLS 1.3

我们根据该标准的当前第15版草案对传输层安全协议 TLS 1.3 进行 简要描述，[78],设计原理的讨论留至第4节。4。TLS 1.3 的设计流程仍在进行 中，在最终完成前预计还将发布多个草案版本。然而，在撰写本文时，该协议的主要组件似乎已相当稳定。

初始TLS 1.3临时Diffie‐Hellman握手的消息流如图2所示。标有星号的消息是可选的或取决于具体情况。“{…}”类型的花括号表示受到握手流量密钥保护，“[…]”类型的花括号表示受到应用流量密钥保护。客户端和服务器交换客户端问候和服务器问候消息，以协商密码套件并交换随机数。实体还交换新生成的Diffie‐Hellman（DH）密钥共享以及相关的组集合（客户端密钥共享、 服务器密钥共享）。

服务器的首个消息批次还将包含不用于密钥建立的扩展（加密扩展）以及可选的早期应用数据。为了实现实体认证，会交换证书和相应的验证信息（证书验证）；如果 服务器通过证书请求要求，客户端将提供这些信息。完成 消息使用基于DH密钥共享派生的握手流量密钥，对整个握手过程的记录生成消息认证码（MAC），从而确保握手的完整性以及密钥确认。如图2所示，完成消息使用握手流量密钥进行加密，而不再像TLS 1.2及更早版本中那样使用应用流量密钥。记录层保护的首条记录是应用数据消息。TLS 1.3仅允许使用AEAD方案来保护此类数据。

实体还可以选择使用预共享密钥（PSK）（PreSharedKey），或使用 PSK/DH组合进行密钥交换。在TLS 1.3中，会话恢复利用预共享密钥（PSK）； 传输早期客户端数据也是如此，这两种情况下使用的预共享密钥（PSK）均在 之前的握手过程中建立。这种所谓的零往返时间（0-RTT）功能允许客户端在其第一组消息中即开始传输数据。有关这些握手模式的详细信息，请参见[78]。

TLS 1.2 RFC中描述的重新协商握手在TLS 1.3中已不再可用。

2.2 互联网工程任务组

互联网工程任务组（IETF）是一个由软件开发者、实施者、厂商和研究人员组成的自发性组织，致力于为互联网创建和维护工程技术标准。IETF的使命很简单，即“让互联网更好地工作”[2]。个人参与完全出于自愿，不存在正式会员资格或相关会员费。IETF的标准化工作被划分为多个领域，每个领域包含若干工作组（WGs）。这些领域涵盖所有协议层，从网络层的IP [75]到应用层的通用协议如超文本传输协议（HTTP）[15],，使IETF成为有关互联网协议标准事务的实际技术论坛。TLS工作组隶属于IETF的安全领域。

互联网工程任务组的标准免费发布为Request for Comment文档（RFC文档）。这些文档通过工作组邮件列表的输入以及全年在IETF会议期间举行的面对面讨论汇编而成。TLS工作组邮件列表异常活跃，是关于TLS RFC文档讨论的重要平台。一旦发布，RFC文档可通过使用扩展进行增强。这些RFC文档旨在提供更丰富的功能和/或针对传输层安全协议的安全增强。

互联网工程任务组采用开放模式进行标准开发。在成员资格和贡献方面不存在准入壁垒，并且遵循多对一开发理念：所有贡献都被集中用于制定单一标准，通过基于共识的流程来决定竞争性选项。传输层安全协议的分析结果来源于内部和外部的混合渠道；工作组成员可在正式的IETF会议或邮件列表中提供分析，而来自工作组外部的研究也可能还应予以咨询。实际上，特别是对于 TLS 1.3，官方的互联网工程任务组流程 已由一个影子流程补充，该流程涉及一小部分不断变化的密码协议设计专家提供的意见。这些意见通过电子邮件以及在各种会议和研讨会上的非正式会议中提交给草案编辑者。由于互联网工程任务组对其标准不收取费用，因此不存在采用的财务障碍。

3 部署后分析

TLS 1.2及更早版本的标准化过程可以说是一种被动响应式的。在针对该协议的攻击被披露后，TLS工作组通过修改下一版本标准，或发布临时建议或扩展来作出回应。这符合我们将称之为设计-发布-破解-修补的标准开发周期。下文将概述这一与传输层安全协议相关的发展过程，重点介绍针对该协议的攻击以及互联网工程任务组对此类攻击的回应。我们关注的是针对协议本身的攻击，而非特定实现中的漏洞（尽管后者的重要性也不容忽视，例如心脏出血漏洞和各种证书处理漏洞）。

我们注意到，每个TLS版本都是在前一个版本的基础上构建的，并在必要时进行修改。目前所有TLS版本都在使用中，客户端和服务器通常支持多个版本。在撰写本文时，SSL Pulse调查中探测的网站几乎有98%支持TLS 1.0，而支持TLS 1.1和TLS 1.2的比例均在80%左右。

3.1 设计、发布、中断、修补

传输层安全协议（TLS）标准于1996年正式诞生，起因是互联网工程任务组（ IETF）决定对安全套接层（SSL）协议的某个版本进行标准化。由于支持电子商务的需求日益增长，从而导致SSL协议的部署日益广泛，这促使了IETF采取这一行动。当时，公开领域中存在两个版本的SSL，即SSLv2和SSLv3[43]。SSLv2存在多个弱点，特别是无法防御降级攻击。最终，互联网工程任务组在[84],（发布于 2011年）中正式弃用了该版本。

1998年，布莱兴巴赫发表了一项针对使用PKCS #1编码方案进行加密的RSA的攻击[26],影响SSLv3。该攻击通过利用服务器生成的具有明显特征的PKCS #1填充错误消息作为 oracle，针对从客户端发送到服务器的RSA加密的预主密钥（见第 2.1节）进行。攻击者通过连续、自适应地调用此oracle，可以逐步缩小预主密钥的取值范围，一旦获得预主密钥，攻击者便能够推导出连接中使用的对称密钥。

TLS 1.0 标准[32]在两段简短的注释中简要提及了此攻击，描述了该攻击以下对策：服务器在收到格式错误的RSA数据块时，应使用预先生成的随机 48字节值作为预主密钥，从而消除 oracle。Bleichenbacher攻击已在多个研究中被重新激活（以各种形式），[52,55,69],最近的案例是DROWN[13],一种跨协议攻击，针对同时支持SSLv2的服务器上运行的所有版本的传输层安全协议。令人惊讶的是，仍有大量服务器支持此旧版协议。

在TLS 1.0[32],发布之后，针对TLS的首个重大攻击似乎是Vaudenay的填充预言机攻击[28,86]。该攻击利用了TLS在其记录协议的MEE构造中使用的特定CBC模式填充格式。TLS工作组最初通过在TLS 1.1规范[33]中添加针对该攻击的特定缓解措施来应对。此举旨在使MEE处理过程的逆向操作——解密、解码、MAC验证（DDM）——的运行时间保持一致。虽然这明显留下了一个微小的时序通道，但当时认为其无法被利用。然而十年后的2013年，AlFardan 和Paterson[8],在其Lucky 13攻击中表明，实际上可以通过一种复杂的时序攻击加以利用。值得注意的是，针对此攻击的最终补丁在OpenSSL实现中需要大约500行新代码，说明了实现DDM操作恒定时间的困难性。此外，多篇后续论文[7,10,11]表明，在某些情况下或针对某些实现，该攻击的变种仍可实施。

2014年的POODLE攻击[71]针对SSLv3表明，SSLv3也容易受到一种相关但可能更严重的填充预言机攻击，其中时序信息被更容易测量的错误信息所取代。由于RC4算法本身存在缺陷（我们将在下文讨论），而这是SSLv3中唯一的其他加密选项，并且POODLE本质上无法修补，因此该攻击使得SSLv3不再有合理的加密选择。

在2008年发布传输层安全协议 1.2[34]之后，我们发现TLS工作组更多地采用了“打补丁”的流程。在此期间，我们见证了针对传输层安全协议的攻击大量涌现。接下来我们将讨论其中的一些攻击。

2009年，雷和雷克斯几乎同时发现了传输层安全协议重新协商攻击。通过 利用攻击者初始握手与诚实客户端和诚实服务器之间后续重新协商握手之间缺乏密码学绑定的漏洞，攻击者能够使服务器误认为流量（包括攻击者注入的流量和诚实客户端的流量）全部来自该诚实客户端。工作组对此攻击的回应是发布了一项强制性传输层安全协议扩展[79]，适用于所有版本的传输层安全协议。该扩展建议在客户端和服务器的重新协商Hello消息中包含相应的完成消息，从而在两次握手之间建立绑定。然而，巴尔加万等[20]提出的三次握手攻击巧妙地利用了这一机制，使得重新协商攻击死灰复燃

各种传输层安全协议恢复和重新协商握手的交互。该攻击完全破坏了客户端认证。

2011年，杜昂和里佐宣布了BEAST攻击 [38]。该攻击影响TLS 1.0，并 利用了穆勒 [70]和巴德 [14],所观察到的链式IV漏洞，尽管其根源可追溯至罗格瓦早在1995年的观察结果。BEAST利用了TLS 1.0中一个事实：CBC加密记录的最后一个密文块会成为下一个待加密记录的初始化向量。这使得具有选择明文能力的攻击者能够恢复低熵明文。BEAST攻击的主要意义在于巧妙地利用在受害者浏览器中运行的恶意JavaScript，实现对低熵、选择明文条件的满足，从而对传输层安全协议发动HTTP会话Cookie恢复攻击。然而，需要注意的是，该攻击需要浏览器存在零日漏洞，才能获得对选择明文所需的精细控制。一年后，相同作者在CRIME攻击中再次利用了这些恶意JavaScript技术（参见 [82]以获取对该攻击的有用描述）。然而，与BEAST不同，CRIME利用了所有版本TLS中固有的压缩侧信道，这一漏洞早在理论上由凯尔西在 2002[54]中指出。有趣的是，尽管BEAST和CRIME攻击可被视为引发了后续大量研究的导火索，但两者并非来自学术研究界，而是出自“黑客”社区（这也部分解释了为何缺乏正式的研究论文来描述这些攻击）。这两种攻击不仅需要对协议的密码学方面有深入理解，还需要了解协议在Web环境中的实际部署方式。

针对CRIME的广泛响应是禁用传输层安全协议（TLS）的压缩功能。然而，这并不能完全解决基于压缩的攻击问题，因为压缩也可能在应用层进行，从而引入类似的侧信道（参见BREACH攻击和TIME攻击）。对BEAST的常见应对措施是切换到在记录协议中使用RC4作为加密方法，因为流密码不会受到 CBC漏洞的影响。不幸的是，长期以来人们已经知道RC4的密钥流存在偏差 [66],，2013年阿尔法丹等[9]利用新发现和已知的密钥流偏差，在RC4被用作传输层安全协议保护手段时实现了Cookie恢复攻击。加尔曼等[45]改进了阿尔法丹等的统计技术，并开发出比[9]中提出的更具实际意义的密码恢复攻击。范霍夫和皮森斯[85]以及布里库特等[27]进一步利用了RC4的弱点。互联网工程任务组于2015年3月在[74]中弃用了RC4。由于这些攻击的高度关注性、弃用声明以及主要厂商决定在其浏览器中禁用RC4，RC4的使用率迅速下降。

继BEAST、CRIME和RC4攻击之后，其他显著的攻击还包括2015年的 FREAK[17]和Logjam 攻击，以及2016年的SLOTH攻击[24]。FREAK和 Logjam均利用了长期广泛存在的对弱出口级密码原语的支持。FREAK攻击影响某些TLS实现，而Logjam漏洞则源于协议缺陷，针对的是TLS中的 Diffie‐Hellman密钥交换。该攻击要求服务器支持出口级加密，并且客户端愿意使用低安全性Diffie‐Hellman组。主动攻击者可说服服务器向请求非出口 DHE密码套件的客户端提供出口级512位组，而客户端随后会接受此弱组作为 DHE握手的有效参数。通过对最先进的离散对数算法进行巧妙的预计算阶段[6]，可快速计算出各个连接的密钥。这类跨密码套件攻击的早期迹象早在1996年就在瓦格纳和施奈尔[87]的研究中出现。这篇论文发出的警告似乎在后续的 TLS发展中被遗忘或忽视了。此外，从版本1.1开始，TLS标准已不再支持出口级密码套件。然而，正如前文所述，几乎所有服务器都支持TLS 1.0，因此仍容易受到此类攻击的影响。

TLS 1.2 从支持 MD5/SHA‐1 哈希函数组合转变为支持用于数字签名的单个哈希函数，这意味着可以支持 SHA‐256 等更强的哈希函数，但遗憾的是，也可以支持 MD5 等较弱的哈希函数。王小云和于红 [88]在 2005年 描述了针对 MD5 的碰撞攻击；SLOTH 攻击 [24]利用此弱点，在使用基于MD5的签名时破坏 TLS 1.2 中的客户端认证。所提出的攻击接近实用，且推翻了一些从业人员认为 TLS 签名所用哈希函数仅需具备第二原像抗性即可的观念。

我们已在较高层次上描述了针对 TLS 的若干最显著攻击以及 TLS工作组 对这些攻击的响应。现在我们转向分析这些攻击是否得到了充分应对，以及标准化过程在多大程度上本可以应对这些攻击。

3.2 有效修复、实现限制与时间滞后

TLS 1.2规范针对Bleichenbacher攻击提供了以下警示说明：

TLS服务器在处理RSA加密的预主密钥消息失败或版本号不符合预期时，不得生成警报。相反，必须使用随机生成的预主密钥继续握手。为便于故障排查，记录失败的真实原因可能有用；但必须注意避免通过时序、日志文件或其他渠道将信息泄漏给攻击者。

乍一看，这种应对措施似乎是充分的。然而，正如亚格尔等[52],人所指出的那样，新侧信道的发现以及更复杂分析技术的发展，使得即使被认为已成功修复的漏洞仍可能遭受Bleichenbacher类型攻击。迈耶等[69]人对传输层安全协议实现的攻击就是这一问题的例证。TLS工作组当时可以选择的一条路径是弃用PKCS#1 v1.5编码方案，转而采用PKCS#1 v2.1编码方案（实现OAEP填充）。这样做将能更有效地抵御Bleichenbacher攻击及其所有可预见的变种。然而，正如TLS 1.1和TLS 1.2 RFC文档中所解释的，为了保持与早期TLS版本的兼容性，该替换并未实施。我们推测，维持向后兼容性以及对临时应对措施的信心，超过了采用PKCS#1 v2.1所能提供的明显更强的安全性。

与填充预言机攻击和Lucky 13的情况非常相似：在TLS 1.1和TLS 1.2中实施了补丁，但随后被Lucky 13攻击[8]证明是不充分的。事后看来，如果更早地改革TLS中使用的MEE构造，并将其替换为有理论分析充分支持的现代设计，整体上将耗费更少的精力，且对协议声誉的损害也更小（尽管[58],取得了积极成果，但其局限性已在[73]中指出）。在TLS 1.2及更早版本的发展过程中，一再出现的模式是，TLS社区（比TLS工作组更大的个人和组织群体）似乎需要看到切实可行的攻击实例后，才会去解决潜在漏洞或采用本质上更安全的解决方案，而不是针对每个具体漏洞逐一打补丁。

对于利用早已被发现存在弱点的原始算法或机制的攻击，一个简单但过于天真的解决方案是：一旦发现某个原始算法或机制存在弱点，就立即将其移除。然而，由于实现和互操作性的限制，这种做法可能并不容易。以FREAK和 Logjam攻击为例，标准化过程本身并无过错：脆弱的出口级密码套件已在 TLS 1.1和TLS 1.2中被移除，这些攻击之所以存在，是由于实践者在实现过程中做出了错误的选择。类似的情况也适用于IV链式漏洞——该漏洞早在1995年就已被知晓，却于1999年被引入TLS 1.0，并直到2006年才在TLS 1.1中被移除。遗憾的是，实际部署的传输层安全协议版本并未如此迅速地跟进，时至今日，大多数服务器仍广泛支持TLS 1.0。另一方面，得益于针对传输层安全协议中 CBC模式和RC4选项的一系列长期攻击，如今所有现代浏览器在初始握手尝试中都会优先选择TLS 1.2和AEAD密码套件。然而，对于SLOTH问题，情况可能并不那么明确。基于MD5的签名方案本不应在TLS 1.2的RFC中被重新引入；而RC4在过去15年多的时间里一直存在大量已知弱点，这意味着其从传输层安全协议中的逐步淘汰本应远早于实际发生的时间，而不应等到攻击手段变得极为强大之后才开始行动。在许多情况下，特别是在支持高级加密标准的硬件可用的情况下，AES‐GCM 可能是加密的一个更佳选择。

尽管有许多研究论文声称TLS握手协议是安全的，但利用各种TLS握手交互的攻击的存在可能令TLS社区感到意外。然而，早在1996年瓦格纳和施奈尔提出的跨密码套件攻击中，就已经出现了问题的早期迹象[87]。也许由于该论文以及后续如[68]等论文中未提出实际攻击，导致TLS工作组对此采取了较为宽松的态度。在2014年的三次握手攻击之前，任何对传输层安全协议的分析都从未充分考虑不同TLS握手之间的细微交互。因此，此类攻击在标准化过程中被忽视也就不足为奇了。然而应当记住，三次握手攻击实际上是2009年重新协商攻击的再现。这表明，在两次攻击之间的时期内，TLS工作组可用的分析方法在广度或强度上均显不足。

我们认为，鉴于TLS的极端重要性，通常情况下应对TLS攻击应采取更为保守的方法。然而，我们认识到，由于TLS部署的大规模性和广泛多样性、主要实现在历史上对编写协议新版本（尤其是TLS 1.2）的迟疑，以及用户（特别是服务器端）更新其TLS版本的速度缓慢，要实现有意义的改变具有挑战性。

3.3 影响和激励机制

在设计‐发布‐破坏‐修补标准化循环中，研究人员的最大奖励来自于制造和推广针对传输层安全协议的高影响力攻击，而研究社区的参与主要以事后方式被鼓励。这种激励模型的明显问题在于，它使已发布标准的用户易受攻击，并给 TLS工作组带来潜在的补丁操作负担。在下一节中，我们将探讨标准化周期的转变是否为研究人员提供了产生影响（以不同形式）的机会，同时积极促进标准化过程。

4 部署前分析

与TLS 1.3及更早版本的开发不同，TLS 1.3的标准化过程具有主动性。它遵循我们所描述的设计-破解-修复-发布周期进行标准开发。通过与研究社区更紧密合作，TLS工作组在最终发布前发布了多个协议草案，并欢迎对协议进行分析。正如下一节将要展示的，这种设计理念同时导致了弱点的发现，并增强了对工作组的设计决策的信心。我们探讨通过考虑可用的协议分析工具的改进，以及设计态度和激励机制的变化，来探讨促成这一新流程的因素。然而，这种方法并非没有复杂之处。接下来，我们还将讨论采用这种方法所固有的挑战，并就传输层安全协议（TLS）的相关流程可能如何改进发表评论。

4.1 设计、破坏、修复、发布

TLS 1.3 的两个主要设计目标是：（i）提高握手协议的效率；（ii）解决在 TLS 1.2 及更早版本中发现的弱点。TLS工作组面临的最初挑战是如何在不完全重新设计一个全新协议的前提下实现这些目标：除了需要开发新的代码库外，新协议还可能引入新的安全漏洞。兰利和张[63]于2013年提出的谷歌的 QUIC加密，为QUIC协议提供了零往返时间（0‐RTT）功能[81],这促使TLS工作组考虑如何降低TLS 1.3中的握手延迟。此外，在此前几年频繁出现各种攻击之后，该协议亟需一次全面修订，以移除弱安全或已失效的功能。

与TLS 1.2及更早版本相比，TLS 1.3的最初几个草案（从2014年4月的第 00版草案开始）引入了旨在增强协议抵御已知攻击能力的变更，例如移除了对压缩的支持，以及移除了静态RSA和Diffie‐Hellman密钥交换机制，仅保留临时Diffie‐Hellman作为唯一的密钥交换方法。此外，通过引入一次往返时间 （1‐RTT）TLS握手，握手延迟也得以降低（此前初始握手需要客户端和服务器之间进行两次往返才能开始交换应用数据）。

在第05版草案及之前各版本草案中引入的两项重要变更，是会话哈希的概念以及重新协商握手的移除。在第04版草案发布时，会话哈希是对从客户端问候开始到客户端密钥交换为止的所有握手消息计算出的一个哈希值。该会话哈希随后被用于密钥派生过程中，以防止主动攻击者在两个不同会话之间同步主密钥，这种技巧曾在三次握手攻击 [21] 中被利用。移除重新协商机制可防止基于重新协商的攻击，其中三次握手攻击再次成为此类攻击的一个示例。

关于TLS 1.3的分析，Dowling等[35]以及科威尔斯等[57]发表了针对第 05版草案的研究，后者采用构造性密码学方法为该协议提供安全保证。他们的研究强调，TLS 1.3在设计上将握手协议和记录协议分离，有助于对协议进行分析，实际上也有助于实现可证明安全。总体而言，这些方法存在差异。（请注意，在 TLS 1.2 及更早版本中，握手协议中派生的应用流量密钥被用于加密握手协议自身的完成消息。这种交互显著增加了对 TLS 1.2 及更早版本分析的复杂性，特别是因为它违反了密钥交换协议的标准不可区分性安全性目标。） Dowling等[35]使用了Fischlin和Günther[41]的多阶段密钥交换模型，证明了握手协议输出的密钥可以在记录协议中安全使用。他们的工作对TLS 1.3的设计提出了若干评论，从而明确地向TLS工作组提供了有益的反馈。

在草案‐07中，我们看到了与TLS 1.2最根本的偏离，TLS握手的密码学核心受到克拉奇克和魏提出的OPTLS协议[62],的强烈影响，并将许多OPTLS元素纳入草案。OPTLS被明确设计为简单且模块化，提供一种采用临时迪菲‐赫尔曼密钥交换的一往返时间、前向安全的TLS握手。OPTLS还支持零往返时间和预共享密钥（PSK）模式，涵盖客户端和服务器在先前已共享密钥的情况下进入协议的使用场景。从草案‐07开始，这种特定模式变得重要，因为原有的 TLS 1.2风格的会话恢复机制被基于PSK的新机制所取代。该草案包含类似于 OPTLS的零往返时间握手和密钥派生方案，采用由克拉奇克设计的HKDF原语 [59]。OPTLS的设计者在[62],中对其协议进行了详细分析，再次为TLS工作组提供了对其设计选择的信心。

然而，应该注意的是，在调整OPTLS以满足TLS需求的过程中进行了重大更改。例如，OPTLS最初假设服务器的长期密钥将是迪菲‐赫尔曼值，并由证书支持。但是，此类证书在当今实践中并未广泛使用，这可能会阻碍TLS 1.3的部署。因此，在将OPTLS‘翻译’为TLS 1.3时，采用了一个两级过程，即服务器使用传统的签名密钥来认证其长期的迪菲‐赫尔曼值。但这又引发了一个现实世界中的安全问题：如果攻击者能够仅一次访问服务器的签名功能，则他将能够伪造凭证，从而长期冒充服务器。因此，决定更改签名范围，使其还包括客户端提供的会话特定信息，从而限制对签名功能的临时访问的价值。这降低了协议的效率，因为现在服务器必须在每次握手中生成一个新的签名。

协议草案‐08和草案‐09中的显著变化包括移除了对基于MD5的签名的支持，以及弃用基于SHA‐1的签名，这部分是响应SLOTH漏洞[24]，同时也是由于实践者和研究人员在TLS邮件列表上施加的压力，要求移除这些薄弱的原语，这一点在TLS邮件列表[46,47]中已有体现。

Cremers et al.[31]使用Tamarin证明器对TLS 1.3进行了自动化分析[83]。他们的模型涵盖了草案‐10，其分析表明该草案满足认证密钥交换的目标。他们在符号模型中证明了这一点，在该模型中，保密性属性的粒度比计算模型中的更粗，但不同握手组件之间的交互更容易分析。Cremers 等人预见了在TLS 1.3系列草案中引入延迟客户端认证机制。该功能允许服务器在握手完成后任意时刻请求认证，类似于TLS 1.2及更早版本中重新协商握手所提供的功能。他们发现了一种潜在的交互攻击，可能破坏客户端认证。该攻击凸显了扩展会话哈希范围以包含完成 消息的严格必要性。这可以防止攻击者将在一个会话中的客户端签名重放到其他会话中，从而将签名绑定到其 intended 的会话。他们的攻击被报告给了TLS工作组，而正式纳入延迟客户端认证机制的草案‐11在设计中包含了必要的修复措施。在并行的研究工作中，Li等[64]使用他们的“多级&阶段”安全模型，在计算模型下分析了各种TLS 1.3握手模式的交互。他们发现草案‐10 在此模型中是安全的。延迟认证威胁未在该研究中被识别，推测是因为该机制尚未正式纳入 草案‐10。

2016年2月，在草案‐12发布之前，互联网协会举办了一场“TLS准备好了吗？”（TRON）研讨会。该研讨会展示了关于TLS 1.3的已发表和正在进行中的分析成果，汇集了TLS工作组成员、研究人员以及行业专业人士，旨在测试当时版本下TLS 1.3的就绪程度。除了前述Kohlwiess等人的工作、克拉奇克和魏，以及Cremers 等人的研究外，还有多个报告展示了协议开发取得的进展以及TLS工作组仍面临的挑战。Dowling 等人 更新了他们之前的分析，覆盖草案‐10[36],，证明了完整的(EC)DHE握手在多阶段密钥交换环境下的安全性。巴尔加万等人推出了ProScript [18],，这是其经过验证的TLS实现miTLS [3,22]的一个JavaScript变体。有趣的是，ProScript还支持提取符号化模型，供 ProVerif协议分析工具[4,25]使用。这项工作强调了将基于证书的认证机制引入 PSK握手可能带来的潜在风险，而这一协议扩展正是TLS工作组当时正在考虑的方向。Berdouche 等人 对TLS 1.3的安全实现开展的研究[16]探讨了如何在保持与现有TLS版本兼容的同时防范降级攻击，并指出了协议中一些从实现角度来看有益的简化措施。

重要的是，TRON研讨会促成了工作组与研究社区之间关于传输层安全协议潜在简化和增强的讨论。其中一些讨论仍在进行中，并为该协议的后续草案提供了参考。研讨会还就TLS1.3的安全需求展开了深入讨论，这促使研究人员和实践者共同提交贡献 [5]。这可能看似令人惊讶，安全性需求分析竟然在流程的后期才进行，我们将在下文对此作进一步评论。

大约在同一时间，加密协议评估面向长期卓越安全性（CELLOS）联盟在 TRON研讨会上使用ProVerif工具进行的一项分析被发布到TLS工作组邮件列表上[12,67]。这项工作表明，草案‐11中的初始(椭圆曲线)迪菲‐赫尔曼密钥交换握手在符号模型下是安全的。

与 TLS 1.3 相关的其他出版物包括 巴尔加万 et al.[19] 关于降级弹性的研究，以及 Fischlinetal.[42] 关于密钥确认的研究。前者提供了如何加强 TLS 1.3 中降级安全性的建议，后者则对所使用的密钥确认机制提供了保障。

一个较小的临时ad hoc会议非正式地称为“TRON2”，于2016年5月举行。在此 次会议上，讨论了该协议的最新修改，展示了进一步的形式化分析，并比较了TLS 1.3的实现。

4.2 可用工具

自2008年发布TLS 1.2以来，密码协议分析工具已发展成熟，现已能够有效服务于主动的标准化过程，从而促进甚至实现了针对TLS 1.3的更具协作性的设计工作。在各个层面都取得了重大进展，从密钥派生和认证加密等底层原语，到认证密钥交换和安全通道的密码学建模等高层原语。

关于传输层安全协议本身的早期分析可参见加耶克et al.[44]在2008年的工作。然而，他们的分析仅涵盖了未经认证的密钥交换。此后，在传输层安全协议的可证明安全性领域已进行了许多改进和进展。一个持续存在的主要挑战是为该协议提供准确的建模，并捕捉其众多交互组件和模式的复杂性。2010年， Morrisseyet al.[72]也对TLS握手协议进行了分析。然而，他们的工作仅考虑了协议的一个截断版本（不加密完成消息），假设使用了CCA安全的加密方案进行密钥传输（这在实际中并不现实，因为TLS实现采用基于PKCS#1 v1.5的 RSA加密），并且依赖于随机预言模型。2012年，亚格尔et al.[51]提出了经过认证且保密的信道建立（ACCE）安全模型，试图应对握手协议和记录协议中密钥使用不当混合的问题；他们使用ACCE模型分析了TLS中某些基于迪菲‐赫尔曼的密钥交换。他们的工作部分建立在帕特森et al.[73],于2011年提出的研究基础之上，后者引入了长度隐藏的认证加密概念，用于建模TLS记录协议所期望的安全目标。其他重要研究还包括克拉奇克etal.[60]和科哈尔et al.[56]的工作。前者分析了多种不同的TLS在ACCE设置中使用单一且统一的证明技术来验证密钥交换方法的安全性，而后者则扩展了亚格尔等人的工作，以证明RSA和DH握手在相互认证环境中的安全性。李等人[65]对预共享密钥密码套件完成了类似的工作。吉森等人[48]在其对TLS重新协商安全性的形式化分析中，明确考虑了多次握手协议运行及其交互，而道林和斯特比拉[37]研究了TLS中的密码套件与版本协商。所有这些研究都提供了可在TLS 1.3最终发布之前用于其分析的技术，并具有进一步扩展的潜力。此外，它们也反映了研究社区对TLS协议日益增长的兴趣，这是研究社区更深入参与TLS 1.3设计流程的必要前提。

在TLS的程序验证领域，一个重要的进展是 2013[3,22]中发布的miTLS参考实现。该miTLS实现在运行代码上整合了软件安全与计算密码学安全方法，以获得安全性证明。这种方法旨在消除对传统可证明安全技术所采用的简化假设的依赖——这些传统方法通常分析的是抽象且较为高层级的TLS模型，并倾向于忽略许多实现细节，以便得到适合生成手工证明（以伪代码形式）的可处理模型；此外，它们往往只关注TLS协议套件的“片段”，而非整个系统。通过这一方法，巴尔加万等人对miTLS中实现的TLS 1.2握手进行了基于周期的安全分析[23]。miTLS实现为TLS 1.2及更低版本的安全实现提供了参考，并与所有主流网络浏览器和服务器实现互操作。miTLS项目不仅导致了诸如三次握手攻击和FREAK等漏洞的发现，还为TLS社区留下了FlexTLS [1]等工具，可用于 TLS实现的快速原型设计和测试。目前，这些工具正被用于评估TLS 1.3。

诸如ProVerif [4]和Tamarin证明器 [83]等自动化协议分析工具的兴起，也可以被视为对TLS工作组的一大助力。以较新的Tamarin工具为例，它对基于DH的协议提供了卓越的支持，并允许实例化无界数量的协议参与者和会话，使其成为TLS 1.3建模及后续符号分析的理想选择。一旦建立此类模型，便可轻松适应协议变更，从而在持续开发过程中发挥不可估量的作用。

可证明安全、程序验证和形式化方法等领域的进步，为设计‐破坏‐修复‐发布标准化循环的蓬勃发展创造了有利的开发环境。此前，由于缺乏这些技术，或在将这些技术应用于TLS等实际协议方面的经验有限，导致发布前可进行的分析工作受到限制，因此对于TLS 1.2及更早版本而言，采用设计‐发布‐破坏‐修补标准化循环是情有可原的，甚至是自然的选择。

4.3 参与、影响和激励机制

在TLS 1.3的开发过程中，工作组已采取了许多积极措施，旨在保护协议免受第 3节中提到的各类攻击。移除对弱哈希函数、重新协商和非AEAD加密模式的支持，以及引入会话哈希机制，都是典型的例子。工作组还做出了一些有助于协议分析的设计选择，例如明确分离握手协议和记录协议。这无疑是工作组回应研究社区需求的积极举措，标志着其设计理念的转变。TRON研讨会也显示出工作组希望让研究社区参与TLS 1.3的设计，并吸纳其贡献的意愿。另一方面，研究社区对TLS协议的复杂性及其多种使用场景有了更深入的认识，并努力相应地调整其分析方法。鉴于多年来研究社区对TLS日益增长的关注，以及分析工具的不断改进，该社区在TLS 1.3设计流程中的贡献能力远超以往各版本协议时期。

能够根据潜在攻击（例如克雷默斯等人[31]和巴尔加万等人[18],所识别的攻击）调整协议，有助于构建更强大的协议，并使工作组能够预先实施变更，有望减少发布后打补丁的需求。与第3节所述的先前流程相比，设计‐破坏‐修复‐发布标准化周期似乎并未改变研究人员的激励机制，在协议最终确定之前仍产生了一系列顶级论文。然而值得注意的是，这些论文提供的是关于TLS 1.3的正面安全结果，而非新的攻击方法。我们认为，这是由于研究社区对传输层安全协议的重要性有了更强的认识，并更加意识到参与其标准化工作比以往开发周期中更具价值。

4.4 改进领域

尽管在分析传输层安全协议（TLS）的研究人员与负责实现TLS的工程师之间的合作方面是一个积极的进展，但部署前分析设计策略仍存在一些困难。越来越多的贡献，无论是来自研究人员还是实施者，都导致了设计观点上的冲突，可能为TLS工作组带来更大的管理开销。未协调的贡献增加也使得TLS 1.3草案规范成为一个快速变化的目标。这增加了所需进行的分析工作量，并使某些分析在短短几个月内就变得“过时”，可能令那些致力于协议分析的人员感到沮丧。这些不同的贡献还在关注TLS 1.3的研究人员之间造成了紧张关系，其中侧重于实现问题的研究人员所提出的改进建议，可能会损害关注可证明安全方面的研究人员的利益。

协议。这在密钥派生和密钥分离领域一直是一个持续存在的问题。分析的时间尺度也可能更加紧迫：不仅快速的变化需要迅速的分析，而且由于工作组/互联网工程任务组希望在发布最终（或接近最终）草案后的几个月内正式发布TLS 1.3，这并未为TLS1.3最终版本的详细分析留下太多时间。对于如此关键重要的协议而言，这是令人遗憾的。

同样，由于科学界与TLS工作组中以工程为重点的参与者之间不可避免地存在理解上的差距，因此可能存在双方沟通不畅的情况。尽管我们并未发现具体案例表明这种沟通不畅或误解已严重阻碍了TLS 1.3的开发，但事实上，研究社区向工作组提交的形式化安全分析确实涉及有关攻击者能力和所使用密码原语强度的假设。有时，这些假设在一个群体中是被充分理解的，但在另一个群体中可能并不明显。一个例子是在基于形式化方法的某些分析中使用理想化密码学假设；另一个相反方向的例子则是，由于使用硬件安全模块来存储服务器私钥，从而对TLS 1.3握手过程施加了限制。

在该流程中另一个潜在的改进领域是TLS 1.3的安全性和功能需求的识别。我们此前注意到，直到2016年2月的TRON研讨会之后，才显现出缺少一套完整且明确的需求。这表明本可以为TLS 1.3采用一种不同的设计流程：需求分析、设计、验证、发布。然而实际情况似乎是，尽管部分需求在早期已确立，但许多其他需求仅在设计阶段的讨论过程中才逐渐浮现。对于TLS这样具有多种使用场景且众多利益相关者参与开发过程的复杂协议而言，期望实现如此线性的流程或许是过于理想化的。当然，“设计”和“验证”步骤可能需要经历多轮循环。另一方面，或许在流程开始时就应举行类似TRON的研讨会，以全面梳理出设计需求。

在整个过程中，一直存在的一个问题是对TLS 1.3相对于TLS 1.2允许的变更程度存在不确定性。最初，变更应是渐进式的，这可能使部分参与者的思路局限于考虑不那么激进的设计。如今，很难再争辩说TLS 1.3不是一次完整的协议重新设计——可以说它更像一个TLS 2.0而非TLS 1.3。如果从一开始就明确这一点，可能会催生哪些新颖的想法呢？

5 超越 TLS1.3

鉴于其重要性和普遍性，这种高度协作、快速推进的主动式标准化过程的成功实施可能为TLS所独有。TLS的案例在多大程度上可以成为趋势引领者，为互联网工程任务组（IETF）乃至其他标准化机构开辟道路，以促进与安全研究人员更紧密的合作？或者在此方面，TLS只是一个特例？研究人员参与标准化工作在安全机制和协议的标准化过程中绝非罕见，但TLS的重要性是否提高了研究社区参与该过程的意愿？

我们现在探讨TLS较新的主动式标准化过程与其他标准化模型（如国际标准化组织和美国国家标准与技术研究院所采用的模型）的内在流程相比有何不同，并质疑这些不同的模型在多大程度上适用于TLS的标准化。我们还评论了这些模型在多大程度上鼓励安全社区的积极参与。

ISO

该标准机构采用封闭模式进行标准化。与互联网工程任务组一样，标准化工作按领域划分，并由技术委员会管理。这些委员会进一步细分为分技术委员会，其中第27分技术委员会（SC27）负责制定和维护有关安全技术的标准。在此分技术委员会内，工作组2负责密码机制的标准化。ISO工作组的成员并非个人，而是国家成员体（NBs），标准化决策由工作组根据参与的国家成员体所提交的意见和贡献做出。这些国家成员体的组建和构成在各国之间显然有所不同，但总体而言，这种模式在贡献方面具有准入壁垒，因为其流程相比互联网工程任务组所采用的开放模式更加“仅限成员”。

从开发理念上讲，这可以说是多对一的模式，即众多成员为一个标准提供输入，但国际标准化组织的安全标准通常包含多种旨在提供安全服务的机制，并不会像TLS RFC文档那样专注于单一协议。第27分技术委员会工作组2的标准中纳入机制通常要求这些机制满足一定的成熟度条件——会参考来自外部的研究成果，在必要时，国家成员体还可进行额外分析。这种成熟度要求可能并不适合TLS 1.3这类动态变化的协议，而标准化过程的封闭性也可能抑制高水平的外部学术参与。此外，国际标准化组织对其标准收取费用，从而造成采用上的财务障碍，这对于TLS这类关键协议而言并非理想状况。国际标准化组织的国家成员体结构也引发了人们对可能参与标准化过程的国家行为体动机的质疑，这对于TLS这种广泛应用的协议来说是一个潜在关切。

美国国家标准与技术研究院

我们在此重点关注美国国家标准与技术研究院采用的竞赛模式。该模式在高级加密标准[40]和安全哈希算法‐3[39]的开发中已成功应用。这种模式不存在准入壁垒，因为竞赛是公开的，且其开发理念是一对一对一的，即仅从候选方案中选出一个作为最终标准化对象，且不将各竞争者的贡献整合到最终标准的创建中。竞赛模式的一个必要条件是算法/协议的需求必须被明确制定并传达。例如，在联邦公报上发布的安全哈希算法‐3竞赛公告中，就包含了最低要求以及评估标准的相关章节。安全哈希算法‐3候选算法的分析由美国国家标准与技术研究院和更广泛的密码学界共同完成，许多评论通过为此项竞赛设立的公开哈希论坛进行交流。大量分析成果最终发表于顶级出版物中（参见[29]以获取完整列表），从而在标准化过程中有效地服务于学术激励机制。美国国家标准与技术研究院还举办了多次SHA‐3研讨会，以收集公众反馈。

SHA‐3 标准化叙事中的一些元素与第4节讨论的 TLS 1.3 标准化过程重叠。部署前分析的开发方法、使用公开邮件列表以及举办公开会议/研讨会，这些方面都体现了 TLS 1.3 过程的相似性。但该过程的不同之处在于，TLS 1.3 的需求在设计开始之前并未完全明确表达。当然，TLS 1.3 过程中没有明确的竞赛要素，这使得其开放模式不同于竞赛模式。另一方面，研究人员和个人研究团队若其想法被 TLS1.3 采纳，将获得巨大收益，无论是个人声誉，还是内部（晋升、公司奖励）或外部（奖项、论文引用）的认可。最后，SHA‐3 竞赛持续了数年（从 2007年 到 2012年），为详细分析提供了更多时间。

与开放模式类似，该最终产品无需成本，这种模型也完全可用于传输层安全协议。然而，我们尚不确定此类模型是否能够支持像TLS 1.3那样快速的协议开发。竞赛模式已被验证适用于分组密码和哈希函数等密码学原语。而像传输层安全协议这样复杂的协议，其范围可能过于庞大，单个研究团队难以独立完成整体设计，因此协作式标准化模型或许更为合适。

6 结论

我们介绍了传输层安全协议（TLS）的标准化过程，从早期版本一直讲到目前接近完成的TLS 1.3。我们描述了TLS 1.2及更早版本的标准开发过程如何符合设计‐发布‐破解‐修补周期，以及流程的转变如何促使TLS 1.3的标准化遵循设计‐破解‐修复‐发布开发循环。我们还评论了影响了TLS工作组设计方法论转变的因素包括：可用的协议分析工具、研究社区的参与程度以及相关利益相关者的激励机制。这种较新的流程相较于之前采用的周期具有优势，因为它能够预先检测并修复弱点，从而产生更强大的协议，并减少发布后打补丁的需求。我们进一步提出，若TLS工作组在标准开发过程中采用需求分析‐设计‐验证‐发布周期，TLS 1.3 的制定过程本可以得到进一步增强。我们还考察了传输层安全协议标准化与多种不同标准化模型之间的关系。

我们发现，当前在互联网工程任务组的开放模式下进行的协作式流程在生成强大协议方面展现出潜力，但美国国家标准与技术研究院所采用的竞赛模式对于 TLS这类协议也可能同样适用。

我们认为，我们的工作是首次尝试对传输层安全协议标准化进行叙事分析，而基于更多案例研究对标准化模型进行详细分类将是一项有趣的未来工作。