題干與適用場景
你的服務有大量長壽命 QUIC 連線，需要取得 TLS Extended Key Update 的前向保密能力。請說明如何協商能力、切換密鑰、處理舊客戶端與丟包，並設計灰度發布與回滾。
IETF QUIC Working Group 的 Extended Key Update 草案基於 TLS Extended Key Update，目標是在長連線中無需完整握手即可刷新密鑰並取得前向保密。它要求雙方在握手中支援 TLS flags 擴充並設定 ExtendedKeyUpdate 旗標；協商成功後，工作階段必須使用擴充流程，不能混用標準 QUIC Key Update。草案仍是 work in progress，生產方案必須鎖定實作版本與互通測試結果。
面試官考察點
面試官會關注你是否理解 QUIC 密鑰更新由握手能力協商、Key Phase 表示與封包號碼空間驅動，是否能說明擴充流程與 RFC 9001 的差異邊界。也要涵蓋雙端狀態機、丟包與重排序、舊客戶端相容、連線遷移、密鑰抹除、灰度指標與回滾限制。高品質答案不會把 Internet-Draft 當成已穩定的 RFC。
回答前需要釐清的問題
- 用戶端與服務端使用哪些 QUIC/TLS 實作與版本，能否同時升級？
- 連線最長持續多久，更新觸發按時間、傳送量還是安全事件？
- 是否允許連線遷移、0-RTT、代理或中間盒參與？
- 舊客戶端無法協商時是保持標準 Key Update，還是拒絕長連線？
- 回滾發生在握手前、協商後還是已經切換密鑰的連線上？
30 秒回答框架
「我先把擴充當成能力協商與連線狀態機問題。握手階段只有雙方都宣告 TLS flags 與 ExtendedKeyUpdate 才啟用；否則使用現有 RFC 9001 路徑。啟用後禁止在同一工作階段混用兩種 Key Update，傳送與接收狀態分別維護密鑰階段、封包號碼與重放視窗。更新觸發由策略控制，丟包與重排序按 QUIC 解密候選與確認邏輯處理，舊密鑰只保留到安全視窗再抹除。發布先灰度能力與實作版本，監控解密失敗、更新耗時、重傳與連線關閉，回滾只針對新握手，已協商連線繼續按原狀態完成。」
分步驟深入解答
1. 明確協商門檻
擴充 Key Update 不能由單端開關決定。握手時雙方必須支援 TLS flags 擴充並設定 ExtendedKeyUpdate 旗標；服務端保存協商結果，按連線而不是全域設定決定狀態。沒有共同能力時走標準 QUIC Key Update，不能傳送對端無法解釋的 Key Phase。
2. 建模傳送與接收狀態
每個方向維護目前密鑰、下一密鑰、Key Phase、最大可接受舊封包視窗與更新計數。傳送方更新後切換 Key Phase，接收方根據階段嘗試目前或下一密鑰，並在成功解密與封包號碼檢查後推進狀態。狀態轉移必須冪等，重複觸發不能跳過階段或重複抹除仍在使用的密鑰。
3. 處理丟包、重排序與確認
密鑰更新訊號可能先於舊密鑰封包到達，也可能反過來。保留有限的舊密鑰與下一密鑰候選，按封包號碼空間與協定確認規則處理，不得無限期保留。解密失敗要區分錯誤階段、驗證失敗與真正的協定錯誤；避免把網路重排誤判為攻擊，也避免用大量候選密鑰放大 CPU 消耗。
handshake flags -> negotiated?
no -> RFC 9001 key update
yes -> extended update state
-> packet decrypt -> confirm -> retire old key4. 定義更新觸發與安全視窗
觸發可以基於連線時長、傳送資料量、密鑰使用次數或安全事件，但要同時考慮壅塞、CPU 與業務延遲。更新前確認新密鑰材料可用，更新後等待足夠確認再抹除舊密鑰。日誌只記錄階段、計數與結果，不記錄密鑰材料、TLS secrets 或可恢復憑證。
5. 相容舊客戶端與連線遷移
舊客戶端繼續使用標準路徑，不能因服務端支援擴充就拒絕所有未協商連線。連線遷移不會重置協商結果，但新的網路路徑可能增加重排序與丟包，應重用同一狀態機並重新觀察視窗。代理或中間盒不應終止並重建未獲授權的密鑰狀態。
6. 設計灰度、指標與回滾
先按客戶端版本、區域或連線比例灰度，記錄協商成功率、解密失敗、Key Phase 不一致、更新延遲、重傳、連線關閉與 CPU 使用。異常時關閉新握手的能力宣告，保留已協商連線按原流程運行；不能強行把已進入擴充狀態的連線切回標準 Key Update。版本鎖定、互通測試與抓包脫敏是發布門檻。
7. 測試互通與密鑰生命週期
測試雙方都支援、單端支援、重複更新、更新期間重排序、丟包、遷移、長時間閒置與連線關閉。驗證舊密鑰在視窗結束後不可用於解密，記憶體抹除與崩潰傾印不洩露密鑰。將草案版本、實作提交、測試向量與異常樣本存檔，避免規範更新後無法重現。
高品質示範回答
我會先確認客戶端與服務端實作版本，再把擴充建模為握手能力與雙向連線狀態機。只有雙方都支援 TLS flags 並設定 ExtendedKeyUpdate 才啟用；否則保持 RFC 9001 標準路徑。啟用後同一工作階段禁止混用兩種更新流程，每個方向維護目前/下一密鑰、Key Phase、封包號碼與有限舊封包視窗。丟包或重排序時按候選密鑰與封包號碼檢查解密，成功確認後再推進階段並抹除舊密鑰。觸發策略按時長、資料量與安全事件配置，日誌只記錄階段與結果。發布按版本、區域與連線比例灰度，觀察協商、解密失敗、重傳、關閉與 CPU 指標；回滾只關閉新握手宣告，已協商連線繼續原狀態完成。最後用互通、長連線、遷移、丟包與記憶體抹除測試鎖定實作版本，因為草案仍可能變更。
常見錯誤
- 單端開啟擴充就傳送新 Key Phase → 對端無法解釋 → 必須雙端握手協商。
- 在同一工作階段混用兩種更新流程 → Key Phase 語意衝突 → 協商後固定一種狀態機。
- 丟包就無限保留舊密鑰 → 記憶體與攻擊面擴大 → 設定有限視窗並按確認推進。
- 把解密失敗都當攻擊 → 網路重排被誤報 → 區分階段、驗證與協定錯誤。
- 回滾時強制既有連線換回舊流程 → 狀態機破壞 → 只停止新協商，保持已協商連線。
- 日誌記錄 TLS secret → 密鑰洩露風險 → 僅記錄階段、計數、耗時與結果。
追問及應對
為什麼不能只透過版本號判斷能力？
版本號只能提示可能支援，協定要求在握手中明確宣告 flags。實際能力還受編譯選項、設定與互通實作影響，必須以協商結果為準。
更新期間收到舊 Key Phase 的封包怎麼辦？
在有限視窗內保留舊密鑰候選，完成封包號碼與驗證檢查後按狀態處理；視窗外拒絕並計入異常指標，不能無限嘗試。
連線閒置很久還要更新嗎？
按密鑰使用量與風險決定。閒置時可等待下一次傳送，避免無意義的控制流量；重新傳送前確認密鑰狀態與過期策略。
如何驗證舊密鑰真的被抹除？
在受控測試中記錄生命週期事件，檢查記憶體、崩潰傾印與除錯介面；使用不可逆的測試密鑰標記，不在生產日誌輸出秘密材料。
草案過期或改版時如何管理？
固定草案版本與實作提交，建立互通矩陣與變更評審；新版本先以獨立能力旗標灰度，不能把工作草案行為無條件當成穩定協定。