3/ Server-side-only escrow less common, less useful, than forcing clients to use a CA for MITM. This is mostly about operational wireshark.
-
-
4/ A lot of PFS fans pop up to object to tls-vis, but don't also insist on PFS for 0-RTT data, which is a much bigger real-world risk.
4 replies 1 retweet 2 likes -
FS is relative to the secret (STEK vs Privkey). In non-DH resumption, the entire resumed connection is not FS wrt STEK, not just 0-RTT data
1 reply 0 retweets 0 likes -
Replying to @grittygrease @tqbf
In TLS1.3 there is no non-DH resume though, only the 0-RTT data misses FS, but is also the most critical data.
2 replies 0 retweets 0 likes -
Read section 2.2: "PSKs can be used with (EC)DHE [..] or can be used alone, at the cost of losing forward secrecy for the application data."
1 reply 0 retweets 1 like -
Adding FS on the resumption with DH is a SHOULD, not a MUST. BoringSSL and NSS support non-FS resumption, for example.
2 replies 0 retweets 1 like -
Replying to @grittygrease @tqbf
Really? OOB PSK with no DH works, makes sense, but resume? KX alg would change across the sessions, which would be bizarrely tolerant.
1 reply 0 retweets 0 likes -
Allowed and supported. Lets servers opt out of expensive public key ops during resumption.
1 reply 0 retweets 0 likes -
Replying to @grittygrease @tqbf
Seems insane on two fronts: 1/ It's incompatible with a best practice for resume: negotiate as normal and only resume if all params match.
1 reply 0 retweets 0 likes -
That avoids attacks where the attacker controls the servers choices by swapping tickets. Also means new alg priorities take.
2 replies 0 retweets 0 likes
2/ makes an even worse mockery of the pro-FS factions, huge *huge* inconsistencies!
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.