TLS, DTLS
doc
tls 1.3
More Privacy, Less Latency tls1.3
A Readable Specification of TLS 1.3
A Detailed Look at RFC 8446 (a.k.a. TLS 1.3)
security
Proving the TLS Handshake Secure (as it is)
On the Security of TLS-DH and TLS-RSA in the Standard Model
Problems With Elliptic Curve CryptographyIn TLS and SSH
SMTP and Transport Layer Security (TLS)
The Illustrated TLS Connection
overview
aead
移除 staic rsa & dh，强制 fs
serverhello后的所有handshake msg全部加密
encryptedExtensions msg可以支持serverhello之前的加密
kdf统一为hkdf
移除 changecipherspec
eddsa等新signature algorithm
移除旧的签名算法、dhe groups
signature_algorithms & signature_algorithms_cert
signature_algorithms 是客户端可以接受的签名类型
signature_algorithms_cert 是能接受的证书签名算法
显然，signature_algorithms可以严一些
legacy_version & supported_versions
为了兼容旧版本tls，legacy_version 设为0x0303 = tls 1.2，supported_versions 的首个内容可以设为 0x0304 = tls 1.3
updating traffic secret
基于第n个application traffic secret派生第n+1个application traffic secret
hkdf-expand-label
nonce
tls 1.2 nonce = 显式的固定IV + SEQNUM
tls 1.3 nonce = 派生的固定IV xor SEQNUM
Resumption
tls 1.3 0-rtt
A Survey of TLS 1.3 0-RTT Usage
0-RTT的风险主要在于replay attack，其根源在于server没有fresh value参与该session处理。同时，不支持fs。
tls 1.3 的 handshake 默认是 1-RTT。对于server主动发包的应用协议，可以做到0.5-RTT。
对于resumption handshake，可以用psk binder标识重连，如果psk是基于之前的handshake share secret派生，那么psk binder标识到psk的映射，可能需要server端安全存储，即stateful session ticket；如果是基于session ticket encryption key (stek) 对 session parameters 做加密，那么涉及STEK的管理，即stateless session ticket。
缓解replay attack的方案，对于stateful session ticket主要是分布式server的重连记录同步（麻烦）、对于stateless session ticket主要是时间限制、STEK的定期更新（有限时间窗可用）。
实际上，应避免0-RTT的请求对server状态产生影响。即，无法确认应用场景的条件下，默认不应开启0-RTT。application & transport 的隔离被破坏了。
0-RTT 还要看一下ALPN。
tls-psk
On the Security of the Pre-Shared Key Ciphersuites of TLS
external-psk
use case 整理得挺好
RFC
RFC5705: Keying Material Exporters for Transport Layer Security (TLS)
EKM: Exported Keying Material
应用层协议复用 tls 密钥协商的 Key Material，派生应用层的相关密钥。
应用层协议可以在tls的client hello、serverhello指定派生的参数（label，context）。
至少可以省1个RTT。
应用层可以使用派生的密钥加密信息，做深层的密钥协商。
RFC7301 ALPN: Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension
在tls连接阶段，把tls上层的协议也选好，可以省1个RTT。
client在client hello中带上自身支持的应用层协议类型，server在serverhello中返回选取的应用层协议类型。
典型场景例如，web server选择over tls的http/1.1, http/2, spdy/2。
RFC7366
rfc5246: data -> mac
data + padding -> cipher
padding不在mac的保护下, padding oracle attack
rfc7366: data + padding -> cipher -> mac
RFC7627
extended master secret, 在handshake消息过程中引入hash value
不同握手过程中，master secrets 不同
attack
Lucky 13, BEAST, CRIME,… Is TLS dead, or just resting?
rsa problem
Protecting RSA-based Protocols Against Adaptive Chosen-Ciphertext Attacks
Padding Oracle Attack
Practical-Padding-Oracle-Attacks-on-RSA
BEAST & Lucky 13 & POODLE
Web场景禁用cbc的ciphersuite
Lucky 13
Lucky Thirteen: Breaking the TLS and DTLS Record Protocols
本质在于针对cbc padding的time analysis
所以，或者random time delay、或者用流式、或者aead、或者设法达到constant time processing的效果。
其弱点比较类似dh里的k-bit问题。
Diffie-Hellman实际强度
Logjam (MITM) => TLS1.3
DH 参数强度 => 优先选用ECDH
Bleichenbacher attack/DROWN attack => 禁用RSA PKCS#1 V1.5 PADDING，使用RSA OAEP PADDING
Hardness of Computing the Most Significant Bits of Secret Keys in Diffie-Hellman and Related Schemes
计算（破解）(log p)^(1/2) MSB 的 dh secret 的复杂度，与计算整个dh secret的复杂度相当。
计算（破解）elgamal public key encryption message类似。
SLtrip Attack(MITM)
HSTS登记网站
Browser配合
coding
Heartbleed => 参数检查
CRIME => tls compression算法禁止选择deflate
nonce misuse
Nonce-Disrespecting Adversaries: PracticalForgery Attacks on GCM in TLS
避免gcm的错误实现引入漏洞
要么像 chacha20-poly1305，aes-ocb一样，基于seq number & key 生成nonce
要么像 aes-siv 之类，实现类似 mac-then-encrypt的机制，生成tag & nonce
www
Does “www.” Mean Better Transport Layer Security?
部署的问题
cert
2016 wosign
robot
tls-rsa
standard
de
BSI TR-02102 Cryptographic Mechanisms
checklist 类型的，比较简洁清晰
cypto -> tls -> ipsec/ike -> ssh
