要約

  • IMAP COMPRESS はタグ付き OK が返った時だけ有効になった。サーバーはその応答を終える CRLF の直後から、クライアントは次のコマンドから圧縮を始める。
  • コマンド、ヘッダー、本文の反復を縮めた履歴は、後続バイトを隠れた状態へ結び付けた。後年の安全指針は暗号文の長さが手掛かりになり得ると示したが、IMAP 固有の侵害を立証したわけではない。

一つの CRLF を境に読み方が変わった

IMAP はもともと、タグ付きコマンド、タグなしデータ、同じタグを返す最終結果で会話を組み立てていた。RFC 4978 は新しい応答種別を設けなかった。サーバーが COMPRESS=DEFLATE を掲げ、クライアントが COMPRESS DEFLATE を送り、既存の OK、NO、BAD が判断を伝えた。

平凡な外形の内側に厳しい待機規則があった。クライアントは結果を見るまで後続コマンドを送れない。OK なら、その次のコマンドを圧縮する。サーバーは成功応答そのものを非圧縮で送り切り、末尾 CRLF の直後からエンコーダーを動かす。拒否なら双方とも古い読み方を保つ。

ここでは一つのバイト位置が権限を持つ。クライアントが早く切り替えれば平文が伸長器へ入る。サーバーが一応答遅ければ、クライアントは圧縮ビットを IMAP 構文として読む。TCP が欠落なく正順で届けても、バイトの意味について合意がなければセッションは壊れる。

capability は効率の保証ではなかった

広告が証明するのは、サーバーがアルゴリズムを理解することだけだった。そのメールボックスが小さくなること、CPU 費用が妥当なこと、通信が秘密になることは保証しない。各送信側は自分の圧縮強度を選び、反対側がそのストリームを復号する。

拒否の規則は意味を狭く保った。同じ方式が別レイヤーですでに働いていれば、サーバーは COMPRESSIONACTIVE を伴う NO を返せる。拡張を二度有効にする操作は不正である。二つの交渉面が見えても、同じ状態変換を二重に積む権限にはならない。

また、全方向が一つの辞書を共有したわけではない。繰り返すクライアントコマンドは上りの履歴を育てる。応答形式、ヘッダー名、メール本文は下りの履歴を育てる。それぞれの送信者が、自分の出したバイトを記憶した。

コマンドの順番とレイヤーの順番は別だった

セッションには SASL セキュリティレイヤーや TLS も加わり得る。送信処理の順序は固定された。最初に COMPRESS、次に存在すれば SASL の署名または暗号化、最後に TLS で保護する。受信側は逆順にほどく。

クライアントが機能を要求した時間順が違っても、この積み重ねは変わらない。交渉の履歴とデータ変換の順序は別の事実だった。COMPRESS は、IMAP を知らない透明な下層ではなく、プロトコル状態を理解する拡張だった。

現行 IMAP4rev2 も、セキュリティレイヤーの切り替えに同じ一般原則を持つ。成功応答の終端が新しい層の開始点を定める。長い接続が途中で表現や保護を変えるには、双方がただ一つの境界を認めなければならない。

反復が辞書の価値を生んだ

IMAP は圧縮に向いていた。クライアントは少数の動詞を繰り返す。サーバーは応答形式とヘッダー名を繰り返す。同じスレッドでは過去の文章が引用される。成長する履歴は、再登場した列を短い参照へ置き換えられた。

添付ファイルは性質が違う。すでに圧縮された書庫や JPEG はほとんど縮まず、有用な IMAP のパターンを辞書から追い出し、二度と現れない素材へ CPU を使わせることがある。仕様は大きな literal の前後で完全フラッシュを行うことや、圧縮しにくそうな形式で処理を弱めることを論じた。いずれもローカルな調整であり、IMAP コマンドではない。

アプリケーション層に近いからこそ、次が構文か、ヘッダーか、本文か、literal かを知れた。その知識が節約を良くし、同時に履歴の責任をアプリケーションへ戻した。

暗号化しても長さは消えなかった

2007 年の RFC 4978 は、安全性について当時の TLS 圧縮の考慮事項を一文で参照した。後に整理された攻撃は評価を変えた。CRIME などは、内容を暗号化しても長さが観測され得ることを示した。秘密と攻撃者が影響できる文字列が同じ履歴へ入ると、推測を変えた際の圧縮長から一致関係が漏れる場合がある。

IETF がまとめた実例は TLS と Web に関するもので、IMAP COMPRESS の攻撃発生や全セッションの脆弱性を証明しない。それでも「圧縮してから暗号化すれば完全」という説明が足りないことは明らかになった。

現在の TLS 指針は、安全だと証明された例外を除き TLS 1.2 の通常圧縮を支持せず、例外にも強い注意を求める。TLS 1.3 は通常のレコード圧縮を削除した。さらに TLS より上の圧縮にも、TLS 自身では直せない漏えいがあり得ると警告する。プロトコルをよく知る圧縮ほど、どの入力を同じ履歴に入れるか決める責任が重い。

隠れた状態には所有者が要る

論理上の IMAP メッセージは変わらなくても、符号化されたバイトは過去のバイトへ依存する。起動点、方向、アルゴリズム、文脈に合意し続ける時だけ利益になる。伸長失敗、資源枯渇、機密性の疑いは、暗号化されたパケットだけ見ても説明できない。

教訓は秘密を常に圧縮するな、という一行ではない。文脈に名前を付け、入力へ影響できる者、出力長を見られる者、履歴の寿命、伸長の資源上限、壊さず無効化する道を決める。記憶する最適化は、すでに状態機械である。

情報源と限界

DEFLATE 形式は RFC 1951、IMAP capability、切り替え境界、レイヤー順、調整方法は RFC 4978 にある。攻撃分類は RFC 7457、現行 IMAP の中核は RFC 9051、現在の TLS 指針は RFC 9325 に基づく。capability は今も IANA IMAP レジストリに載る。これらは現在の普及率を測らず、IMAP COMPRESS 固有の侵害も報告しない。