TLS 1.3 中使用的 ticket_age_add 和 obfuscated_ticket_age 是什麼

在 RFC 中，我只找到這樣的描述：

This addition prevents passive observers from correlating connections unless tickets are reused

ticket_age_add是隨機生成的，obfuscated_ticket_age通過添加obfuscated_ticket_age到票的老化時間來計算。

在我看來，由於 PSK 是明文發送的，它需要包含也是明文的老化時間，中間人可能知道這張票的老化時間，所以我們不需要 obfuscated_ticket_age直接使用老化時間。

問題1：

如果我們不想讓中間人知道老化時間，我們可以去掉 obfuscated_ticket_age簡單的，對吧？為什麼伺服器需要這些資訊？只是用它來檢查票的真實生命週期？

問題2：

如果客戶端使用的是ticket的真實老化時間而不是ticket obfuscated_ticket_age，如果中間人知道ticket的老化時間，對端點有什麼危害？

這些參數的重點是對自發出票證以來的時間進行編碼。這個時間是必要的，以便伺服器可以將其 0-RTT 重播的風險限制在一個適度窄的視窗中。0-RTT 的主要問題是可能會擷取和重放 ClientHello 和後續的 0-RTT 數據。

如果客戶端的 0-RTT ClientHello 被重放，擁有自發出票證以來的時間允許伺服器在時間與自己的預期相差太大時快速拒絕 0-RTT。這限制了 ClientHello 可以重放的時間，使其他反重放技術更可行。例如，伺服器可能會記住它在短時間內收到的每個 ClientHello，儘管更有效的機制肯定是可能的。

當伺服器接收到帶有 0-RTT 的 ClientHello 時，它可以obfuscated_ticket_age從客戶端的角度使用來確定票證的年齡。伺服器將此與它自己的票齡視圖進行比較——它記住它發出票證的時間和價值，ticket_age_add並且可以使用這些值來恢復它自己和客戶端的經過時間的看法。（伺服器可能還會記住它與客戶端之間往返時間的估計，以便在其評估中考慮傳輸延遲。）

如果兩個時間相差太大，伺服器可以快速有效地拒絕 0-RTT。伺服器需要為諸如相對時鐘漂移、往返時間估計錯誤以及傳輸協議的重傳延遲等事情留有一點餘裕。預計任何一方的值都為 5 到 10 秒。

該ticket_age_add欄位是一種簡單的加密形式，相當於一次性密碼。 ticket_age_add是從客戶端添加到經過時間的隨機值（或難以猜測的偽隨機值）。這種加密確保客戶端不會暴露自票證發出給伺服器以外的任何人以來的時間。如果這沒有以某種方式被掩蓋，被動的觀察者可能會利用時間將這個連接嘗試與之前的連接聯繫起來。該值被添加到實際經過的時間（模 2 32）以獲得obfuscated_ticket_age.

引用自：https://crypto.stackexchange.com/questions/60925