本記事のタイトルの “より強力な電子メール配送パスの認証” というのは、この文書のAbstractにある “a new mechanism based around a more strongly authenticated email delivery pathway” を参考にさせていただきました。

RFC4686(DKIMの関連文書、Informational)をObsoletesする想定のようです(Standards Track)。

念のため補足しますが、本記事の作成時点でDKIM2は普及しているものではありません。今後仕様化されるかどうかも現段階では分かりません。

各章のメモ

I-Dの各章に書かれていることを、かいつまんでメモします。

不正確な箇所もあるかと思いますので、詳細は原文をご確認ください。

1. Background and motivations

様々な課題、例えば電子メールが配送経路上で変更された際のDKIM1署名の検証失敗、ARC署名の信頼性、DKIMリプレイ攻撃、正式な仕様が未策定のフィードバックループ運用、バックスキャッターといったものを解決するため、DKIM2ではチェーン (forwarding chain) 上の各ホップ (MTA相当) で以下を行うこととしています。

配送パスの検証、変更の記録 (検証時に復元できる仕組みも)
宛先 (次の配送先) の情報を署名に含めて保護
一定の期間、制御メッセージ(bounces, abuse reports and delivery notifications)を前のホップに戻すことを保証

補足として、DKIMリプレイ攻撃については関連文書(DKIM Replay Problem Statement)があり、このDKIM2の背景に関連しそうな内容がまとめられています。

2. Design Goals

以下のような設計目標が挙げられています。

電子メールの相互運用(interoperate)
シンプルさ
暗号処理の数の維持または削減
オプションを無くし仕様すべての必須化

3. Basic ideas

以下のような方式が挙げられています。

relaxed/relaxed 方式のみ許可 (DKIM1のsimple相当は無し)
各ホップは連番付き (iタグ) のDKIM2ヘッダーを追加
配送できない場合、DSN は元の送信者に直接送信されず、DSNを処理できるホップに到達するまで “送信パス” を遡って送信
DKIM2ヘッダには RFC5321.mail-from(エンベロープFrom)、RFC5321.rcpt-to(エンベロープTo) の情報を含み(ヘッダのFromやToでなく)、これらは署名対象
電子メールの内容を変更する中継者は、その変更を記録
電子メールを複製する中継者は、その変更を記録

4. How the aims of DKIM2 are achieved

各課題の解決方法として、以下のような要素が挙げられています。

署名対象となるヘッダの固定化 (つまり、すべて必須)
DSN が直前のホップに送信されることにより、バックスキャッターの防止、転送時の転送先アドレスの漏えい防止、ESPやメーリングリストでの処理の簡素化
メーリングリストのDMARCに関する問題については、配送の途中で電子メールの内容が変更された場合にも、変更前の内容に復元するための代数(algebra)を定義 (なお、この代数については、DKIM2 自体とは別のドキュメントに含まれることを示唆)
送信ゲートウェイが最初のホップとなる (最初の署名を行う) ケースや、受信ゲートウェイが信頼されている前提で電子メールの変更を復元する必要性がないケースを考慮
DKIM2ヘッダにはタイムスタンプ(およびその有効期限)と、FromおよびTo(RFC5321.mail-from、RFC5321.rcpt-to)を含むので、リプレイ攻撃に耐性がある
配送されるメールは宛先(RFC5321.rcpt-to)ごとに1通ずつ分けられて、それぞれ署名される (補足：分けることにより、RFC5321.rcpt-toを署名対象に含める点や、一意なDKIM2ヘッダを生成する点と整合性を確保)
署名が一意になるので、もし受信者が署名が重複したメールを受け取った場合には、キャッシュによるリプレイの検出や、レピュテーションによる評価が可能
新旧の暗号化アルゴリズムを段階的に移行できるよう、1通のメールに新旧それぞれの暗号化アルゴリズムによる複数の署名を追加して良いこととし、旧アルゴリズムにのみ対応した評価者が検証失敗せずに済むよう配慮 (例えば今後のPQC(耐量子計算機暗号)への移行等の想定も含む)
DKIM2 で暗号計算が行われるタイミングは、電子メールが以前のホップで変更されていない一般的なケースにおいては、最初の DKIM2 署名と、前のホップで適用された署名のチェックの際 (さらに、フィードバックを提供する場合はフィードバック要求を含む署名のチェック、さらにその電子メールが疑わしいと判断される場合にはそのチェック等)

5. DKIM2 header fields

DKIM2ヘッダ用のフィールドです。

Field identifier	Explanation
i=	Sequence Number (from 1 to N)
t=	Timestamp
ds=	Signing key identifier (domain & selector)
a=	Crypto algorithm(s) used (unless combined with b= to allow for multiple signatures on the same email, see discussion of crypto-agility above)
b=	Signature over hash value strings (DKIM uses b=)
bh=	Body hash value (see discussion)
h=	Extra headers signed by this hop
m=	Indicates if mail has been modified or exploded
z=	Next hop does not support DKIM2 (see below)
mf=	RFC5321.mail-from
rt=	RFC5321.rcpt-to
fb=	feedback requested for this email
n=	a nonce value (could use for database lookup for DSN handling)

出典：DKIM2 Why DKIM needs replacing, and what a replacement would look like

いくつか補足します。

z=は、配送チェーンの途中で、DKIM2の処理が終わりを示すものです(z=yのとき)。電子メールがその配送経路の途中までDKIM2署名されてきたものの、次のホップがDKIM2に対応していない場合に使用されます。

m=は、その電子メールが変更もしくは展開されたことを示します。下表のとおりです。complexの場合には復元できません。

Value	Purpose
nomodify	Any hop that adds this requires no modifications; anybody later hop must either reject it or agree to pass it on unmodified
header	This hop has modified the headers; a separate header lists the algebra to revert the changes
body	This hop has modified the body; a separate header lists the algebra to revert the changes
complex	This hop has done something complex and there is no way to revert it

出典：DKIM2 Why DKIM needs replacing, and what a replacement would look like

mf=は、RFC5321.mail-fromで、rt=は、RFC5321.rcpt-toです。メールヘッダ内のFromやToではありません。

なお、バージョン番号(v=)はありません。ヘッダ名がDKIM2なので、それでバージョンを区別するとのこと。

t=のタイムスタンプについては、配送されるメールのタイムスタンプは一週間以内(MUST) であることとされています。古いタイムスタンプの署名は認証成功しないということです。バウンスの場合、ホップ i=1 のタイムスタンプから 2 週間以内に送信元に返される必要があるようです(たぶん往復分)。

6. Checking hashes

DKIM2署名を含む電子メールを受信した際の検証処理についての説明です。

Step1で最新のDKIM2署名をチェックし、ハッシュと送信元と送信先の一致を確認、Step2で最初のDKIM2ヘッダをチェックします。

電子メールが変更されていた場合に、復元して検証する点についても触れられています。変更を行う中継者の評判が高まり、十分な信頼が与えられると、復元の手順を省略できる点も添えられています。

変更が大きく(例: URL の書き換え、MIME 部分の削除)、復元することができない場合、評価者(受信者)は変更を行ったシステムを信頼する必要があります(MUST)。信頼できない場合は、メールを拒否すべきです(SHOULD)。

また、前述のとおりDKIM2ヘッダ中のハッシュは一意なので、リプレイ攻撃を防ぐことができます。最初に届いたメールが正規のオリジナルであるという前提が必要かと思いますが。

7. Feedback loops

(省略)

8. DKIM1/DKIM2 Interworking

1つのメールにDKIM2署名とDKIM1署名は共存できます。

DKIM2 対応サーバー(次のホップ)は、SMTP 拡張機能のバナーでアナウンスします。また、DKIM2 対応のサーバーに接続する DKIM2 対応クライアント(送信元)は、RCPT TO コマンドにパラメタ (rcpt parameter) を追加し、宛先ドメインが DKIM2 対応であるかどうかを照会します。

例：RCPT TO: person@example.com DKIM2

SMTP 通信の途中で DKIM2 ヘッダーを生成して署名するのは効率的ではないので、特定の宛先が DKIM2 をサポートしているかどうかを記録するデータベース(キャッシュ相当)の必要性についても言及されています。

(参考) DKIM2の話は、ARCの話ではない

このI-Dは、ARCとの連携はせず(排他ではない)、またARC2でもなく、DKIM2です。

このDKIM2のI-Dの著者の1人であるRichard Clayton氏は、ARCを不要とすることがDKIM2の目的の1つであるとコメントしています(別途、公開されているDMARC WGのML内のやり取りより引用)。

One of the aims of DKIM2 is to make ARC unnecessary, and in particular to ensure that cases where an intermediate system must be trusted relate only to improving your heuristics which detect DKIM-replay or where you have a contractual relationship with that intermediary.
出典：［dmarc-ietf］ Re: What do do with ARC, Re: Discussion Thread
※改行を追加してあります

ARCは、GoogleやMicrosoft等が既に使用しており、その有効性を主張する意見もあると思いますが、このDKIM2についてはそのARCが不要となるような仕組みとなることを想定しているようです。

また、中継者が信頼されなければならないケースは、DKIMリプレイ攻撃のヒューリスティック検知を改善するときと、中継者との契約関係(ゲートウェイやフィルタ等)があるときに限るようにすると言及しており、これは従来のARCにおける中継者の信頼性を確認する仕組みについての課題に関連する部分でもあります。

本記事では、an intermediateを中継者と記載しています。

同じやり取りの中で、ARCに対して以下のような点も指摘しています。

The problem with ARC is that you have to trust the intermediary is documenting what they received and not inventing a message and lying about its provenance. Trusting MAGY (Microsoft, Apple, Google, Yahoo) the IETF and the Harvard alumni forwarder is probably OK. After that (and possibly even before) opinions start to vary.
出典：［dmarc-ietf］ Re: What do do with ARC, Re: Discussion Thread
※改行を追加してあります

以下は、別の方(DMARCbisの著者の方)からのコメント。

There aren’t a lot of malicious forwarders. I can’t even remember the last time I got mail from one. In most cases, if you get forwarded mail, you can use the reputation of the original sender. DKIM2 lets you tell mechanically that it really was forwarded, a key difference from ARC.
出典：［dmarc-ietf］ Re: What do do with ARC, Re: Discussion Thread
※改行を追加してあります

With ARC you cannot tell whether it’s really a forward, so the reputation of the forwarder is the only thing you have.

With DKIM2 a malicious forwarder would have to take a signed message sent to that forwarder, make changes, and sign it again and send it out.

DKIM2 puts the envelope recipient in the signature so you can’t forward some random message you found in an archive, you can only forward a message sent to you, and it has date stamps, so it has to be a message
sent to you recently.
出典：［dmarc-ietf］ Re: What do do with ARC, Re: Discussion Thread
※改行を追加してあります

あくまで公開された議論の切り抜きなので、詳細は該当のスレッドをご確認ください。上記のやり取りがDKIM2の文書に含まれる訳でもありません。

感想

DKIM2は、強力そうな仕組みです。

昔からある電子メールという仕組みを今後も安心して使えるようにするためには、こんなにも重厚な工夫が必要ということなのでしょう。その現状に、歴史的な深みを感じる方もいれば、逆に大変そうだなと思う方もいるのかもしれません。見方によっては、レガシー技術を維持することに対するある種の警告のようにも感じます。

方式に関しては、RFC5321.mail-from、RFC5321.rcpt-toの情報がヘッダに書き込まれて署名対象となる点については、SMTPのレイヤと電子メールのデータ部分(ペイロード)のレイヤをまたぐ処理なので、何かしら例外に注意が要る気がしました(と言っても思いつきませんが)。

あと、メールを宛先ごとにバラして暗号処理するのは、重たそうです。受信者側の検証も同様に。

なお、SPFやDMARCには触れられていませんが、それは別の話になるかと思います。仮にDKIM2が普及するとしたら、既に普及しているDMARCの(商業的なものも含めた)意義はヘッダFrom(のalignment)くらいですかね。

ちなみに、MLM(メーリングリストマネージャ)のサーバソフトウェア等が動作する環境においては、MLMは従来通り電子メールの変更は行うものの、DKIM2署名を行うところまでは自ら処理(実装)しない可能性も考えられます。その際、MLMの後段のMTAにDKIM2署名を任せるにしても、そのMTAはMLMが変更した内容を確実に知る術がない、となると思うのですが、そこはおそらく別文書になるらしい代数(algebra)がその伝達をしてくれる…のかな？後段のMTAがさらに変更する場合は、その変更も記録後にDKIM2署名を行う必要性がありそうです。

(追記) その後の状況を補足

色々な詳しい方がアクション、リアクションをされているようです(雑)。

以下は、別の方(DMARCbisの著者の方)による、Sympa (MLMのサーバソフトウェア) の開発者用メーリングリストへの投稿です。DKIM2においてMailmanとSympaは考慮されていることも示唆。Mailmanの方は公開されたやり取りは見当たらず。

devel – [devel@sympa] DKIM2 and Sympa – arc

以下は、DKIM2の著者の方がIETFのdkim WGのメーリングリストに投稿されたメールです。たくさんの返信があり、今回のI-Dに対し、多くの方が賛同されているように見えます。このDKIM2のテストを実施するためにエンジニアの予定を既に確保してあるというコメントも。

[Ietf-dkim] PROPOSAL: reopen this working group and work on DKIM2

ちなみに、dkim WGのCharter(Draft)には、以下の記載も。DMARCの認証方法にDKIM2を追加することに言及しています(あくまで勝手な推測程度の例ですがauth=dkim2のようなタグとか)。

This working group will also update the following existing document(s):

・DMARC to add DKIM2 as an additional authentication mechanism
出典：Domain Keys Identified Mail (Charter)