RFC 7685：tls ClientHello填充扩展

简述
    此备忘录描述了可用于将ClientHello消息填充到所需大小的传输层安全（TLS）扩展。

1.介绍
连续TLS [RFC5246]版本增加了对更多密码套件的支持，随着时间的推移，已经定义了更多的TLS扩展。 这导致TLS ClientHello的大小增长，额外的大小已经导致一些实现错误。 这些实现错误中的至少一个可以通过使ClientHello更大来改善。 这是希望的，因为难以实现对受影响的实现的全面修补。

    此备忘录描述了TLS扩展，可用于将ClientHello填充到所需的大小，以避免由某些ClientHello大小导致的实现错误。

2.需求表示法
    略

3.填充扩展
 
  新的扩展类型（填充21）被定义，可能包含在ClientHello消息中。
    

  enum {
       padding(21), (65535)
  } ExtensionType;

    扩展的“extension_data”由任意数量的零字节组成。 例如，最小的“填充”扩展是四个字节长，并且被编码为0x00 0x15 0x00 0x00。 十字节扩展将包括六个字节的“extension_data”，并且将被编码为：
   00 15 00 06 00 00 00 00 00 00
   |---|   |-----| |--------------------|
     |         |             |
     |         |             \- 扩展数据: 6 字节0
     |         |
     |         \------------- 16比特, 扩展数据长度
     |
     \------------------- 填充扩展的类型

 客户端必须用零字节完全填充填充扩展，尽管填充extension_data字段可能为空。

  服务器不得回显此扩展。

4. 使用示例
作为示例，考虑希望避免发送具有256和511字节（包括）之间的TLSCiphertext.length[详解tls协议]的ClientHello的客户端。考虑这种情况是因为已知至少一个TLS实现在接收到这样的ClientHello记录时挂起连接。

   在正常构建ClientHello后，客户端可以向长度添加四个字节（以考虑握手协议的“msg_type”和“length”字段），并测试所得长度是否落入该范围。如果是，则可以添加填充扩展，以便将长度推到（至少）512字节。

   注意，如果原始ClientHello大小在505和507字节之间，则利用握手协议开销，记录有效载荷将在509和511字节长之间。由于扩展不可能占用少于四个字节的空间，因此在这些情况下，附加的填充将不得不将ClientHello记录有效负载扩展到512字节以外。

5.安全注意事项

    填充扩展的内容可以用作隐蔽通道。 为了防止这种情况，内容被要求是全零，虽然扩展的长度仍然可以用作小得多的隐蔽通道。

6. IANA考虑因素

    IANA已在“ExtensionType值”注册表中永久注册了值21（填充）。

7. 规范性引用文件
    rfc2119
    rfc5246