PSK_binder， PSK AND TICKET。

客户端和服务端通过(EC)DHE 的方式建立了连接，当握手完成之后，也就是服务端收到客户端的 FINISHED 报文之后，服务端可以发送多条 NST 报文，该消息将一个 ticket 键值和从重用主密钥导出的 PSK 建立了关联。

NST 报文可以一次发送多条，也可以捕获特定事件之后再发送，比方说服务端发起一条 post-handshake 认证报文。 　　看一下 NST 报文的格式：

struct {
      uint32 ticket_lifetime;
      uint32 ticket_age_add;
      opaque ticket_nonce<0..255>;
      opaque ticket<1..2^16-1>;
      Extension extensions<0..2^16-2>;
  } NewSessionTicket;

ticket_lifetime 用 32bit 网络字节序 unsigned 整型表示。服务端绝对不能使该值大于 604800，也就是７天。该值为０，表示应当立刻丢弃。客户端不应当缓存 lifetime 超过七天的 ticket，服务端对该 ticket 的有效期应当小于 ticket_lifetime。

ticket_age_add 　一个满足随机性，安全生成的 32bit 数值，该数值用于混淆客户端发送过来的 ticket_age。客户端将 ticket_age 加上该值，然后对 2^32 取余。服务端对于每个 ticket 必须重新生成一个新的 ticket_age_add。

ticket_nonce 　独一无二的 ticket_nonce。

extensions 　目前 NST 报文只允许使用一种拓展，即 max_early_data_size，即发送 0-RTT 数据时，客户端可以发送的最大数量应用报文。只考虑应用数据，也就是明文但是不包含 padding 和报文种类等多余的数据。 ticket 　 ticket 的键值会被使用为 PSK-identity，ticket 本身是一个含混的标签（这一点很容易理解，对客户端而言他是一个身份），它可以是数据库查找的键值，或者是一个自加密－签名的数值。RFC5077 提供了一种推荐的 ticket 构建方法： 服务端使用两种不同的 key:128bit 的 AES-CBC 加密，和 256bit 的 HMAC-SHA-256

struct {
      opaque key_name[16];
      opaque iv[16];
      opaque encrypted_state<0..2^16-1>;
      opaque mac[32];
  } ticket;

key_name 用于鉴别不同的 key，因此服务端可以轻松鉴别自己签发的不同的 ticket。key_name 应当能够避免碰撞攻击。encrypted_state 使用 AES-CBC 模式同 IV 进行加密，MAC 码使用 HMAC-SHA256 对 key_name 和 IV 进行计算。

struct {
      ProtocolVersion protocol_version;
      CipherSuite cipher_suite;
      CompressionMethod compression_method;
      opaque master_secret[48];
      ClientIdentity client_identity;
      uint32 timestamp;
  } StatePlaintext;

StatePlaintext 存储着包含 master_secret 的 TLS 会话状态，服务端利用时间戳来判断会话状态的过期，client_identity 字段包含认证方式和秘钥交换算法，具体实现的时候可以根据需求来选择代码进行实现。我个人考虑 TLS1.3 不需要提供 certificate_based 的 session 存储，我们只需要提供 psk 的存储即可。值得注意的是，下面的 psk_identity 并不是 TLS1.3 的 psk_identity。

enum {
      anonymous(0),
      certificate_based(1),
      psk(2)
} ClientAuthenticationType;

  struct {
      ClientAuthenticationType client_authentication_type;
      select (ClientAuthenticationType) {
          case anonymous: struct {};
          case certificate_based:
              ASN.1Cert certificate_list<0..2^24-1>;
          case psk:
              opaque psk_identity<0..2^16-1>;   /* from [RFC4279] */
      };
   } ClientIdentity;

同当前 ticket 相关联的 PSK 计算方式如下： HKDF-Expand-Label(resumption_master_secret, "resumption", ticket_nonce, Hash.length) ticket_nonce 的独特性保证了 PSK 的独特性。

服务端通过 NST 报文，将 ticket 发送过来。现在客户端进行第二次连接，客户端需要发送 CH 报文来发送自己的 PSK 信息，CH 报文必须包含 pre_shared_key 拓展，该拓展的格式如下： struct { opaque identity<1..2^16-1>; uint32 obfuscated_ticket_age; } PskIdentity;

  opaque PskBinderEntry<32..255>;

  struct {
      PskIdentity identities<7..2^16-1>;
      PskBinderEntry binders<33..2^16-1>;
  } OfferedPsks;

  struct {
      select (Handshake.msg_type) {
          case client_hello: OfferedPsks;
          case server_hello: uint16 selected_identity;
      };
  } PreSharedKeyExtension;

identity 对应于我们上文定义的 ticket，也可以是外部方式建立的一个标签。 　　 obfuscated_ticket_age 对应于上文中我们说的加了混淆之后的 ticket_age，对应的元素可以在服务端发送的 NST 报文当中找到。如果该 PSK 身份不是通过 NST 报文建立的，那么这个字段必须为 0。 　　 psk_binder 是关键信息，用来将一个 PSK 和当前的握手信息，与上一次通过 NST 报文建立的握手信息创建关联。使用 HMAC 对部分 CLIENTHELLO 报文－ CLIENTHELLO 报文从头到 PreSharedKeyExtension.identities （即不包含 binders 字段，因此我们知道 PreSharedKeyExtension 必须是最后的拓展）进行计算，得出 binder。我在这里对于 HMAC 输出的长度存疑，我看到 PskBinderEntry 的长度为 49×8 位，但是我知道的 SHA-384、SHA-256、SHA-1 都没有这么长的输出长度。

binder_entry_key =
   HKDF-Expand-Label(Binder_Key, "finished", "", Hash.length)
 verify_data =
      HMAC(binder_entry_key,
           Transcript-Hash(Truncate(ClientHello1)))

另外一点需要注意的是如果服务端和客户端之间发送过 HelloRetryEquest，那么第二次计算的内容应当为： Transcript-Hash(ClientHello1, HelloRetryRequest, Truncate(ClientHello2))

对于服务端，回复的 PSK 拓展，为从 0 开始的选择的客户端的 PSK 序号。