ARC認証の整理しておきたいポイント

2022-08-212024-08-14

当サイトには広告を含みます。

当サイトでは、広告掲載ポリシーに沿って広告を掲載しています。
※広告でなく、単に商品やサービスを自主的に紹介しているだけという場合もあります。

"オススメ" として紹介している商品やサービスは、個人的にそう思えたものだけです。

共感、興味をもっていただけるものがあればご利用ください。

[年末年始] Amazonホリデーストア

+1,000P獲得できるAmazonプライム入会方法

電子メールの送信元ドメインが詐称されていないかを検証する送信ドメイン認証 (Sender Domain Authentication)。

本記事は、ARC(Authenticated Received Chain)認証についてまとめたものです。

SPF、DKIM、DMARC、ARC、BIMIといった送信ドメイン認証のまとめ記事はこちらです。

本記事では、整理しておきたいポイントを中心に記載しています。ネット上に解説記事が多そうな内容については省略している場合があります。

基本

ARCの認証対象と認証成否

メールヘッダ(ARC-*ヘッダ)にある電子署名を認証します。
このARC-*ヘッダは、メールを中継するシステム(ARC対応のMTA等)によって追加されるたびに増えます。
電子署名の中で指定されたドメインのDNSに登録されたレコード(DKIMと同様)に基づいてその署名を検証する等、ARC認証に必要な一連の処理を行い、正しいものであると判断できれば認証成功です。
ARC認証の成功により、最初から最新までの全てのARC署名(i=1～N)が有効なChainを構成していることを確認できます(“chain of custody”：認証/管理の連鎖のようなイメージ)。
DKIM単体の場合、メールの再配送時に認証情報が無効になってしまうことがありますが、ARCの場合はChainとして保持できます(再配送とは、indirect mail flow：メーリングリストに投稿されたり、別ドメインのメールアドレス宛に転送されること)。これがARCの特徴であり、SPF、DKIM、DMARCにおける、再配送時に認証不可になってしまうという課題を緩和できます。
ARCは、DKIMと同様の署名が用いられていることから、(語弊はありますがイメージとして)DKIMを再配送に対応させたものとして捉えると理解しやすいかもしれません。
DNSレコードを保有するドメインの管理元により、「メールに署名することを認められたメールシステムにより、最初から最新までのARC署名(i=1～N)がそれぞれ追加され、また署名の改ざんもされていない」という点を担保します。詳細は長くなるので後述します。

認証時の動作

メールを受信する側が、上記の認証を行います。
ARC認証の際には多くの検証処理が行われます。
詳細は、RFC 8617の”5.2. Validator Actions”に記載があります。またARCの検証時にはDNS問合せが多く発生します(“11.3.3. DNS Overhead”)。
以下は備忘用です。
- AMSヘッダの検証は、最新(そのメールヘッダ内で最も大きな値のi=N)のものに対して行われます。
  任意で、全てのAMSヘッダの検証を行い”最初にpassしたARC署名のiの値”を調べることもできます。
- ASヘッダの検証は、最新から最初までの全てのものに対して行われます。
- この検証結果は、ARヘッダに記載される必要があります(SHOULD)。

ARC対応に必要な設定

ARC対応に必要な設定は、DNSレコード登録の他、ARC署名追加機能の実装が必要です(鍵の準備を含む)。DNSレコードや鍵は、DKIMで使用するものと兼ねることができます。
SPF、DKIM、DMARCに対応していないドメインであっても、ARC対応することはできます。
各送信ドメイン認証技術の普及の仕方によると思いますが、基本的にSPF、DKIM、DMARCに対応した上で、必要に応じARC対応もすることになるでしょう。

認証結果

ARCの認証結果は、”none”,”fail”,”pass”のいずれかです。
- RFC 8617の”4.4. Chain Validation Status”、”10.1. Update to Email Authentication Result Names Registry”に記載されています。
- この認証結果は、以下で使用されます。
  - Arc-Sealヘッダ内のcvの値
    i=1の場合はnone
    i=2以降の場合はfailもしくはpass
  - ARC-Authentication-Resultsヘッダ内のarcの値
  - Authentication-Resultsヘッダ内のarcの値

詳細

RFC

ARCの仕様は、RFC 8617 で定義されています。

導入ステップや運用ポリシーに応じた調整のポイント

まず参考として、ARCの仕様策定や普及の状況についてです。
- ARCの仕様を定めたRFC 8617は、2019年7月に公開されたもので、Experimentalの扱いです。比較的新しい仕様ということです。
- 普及状況としては、Gmailは2017年5月にARC対応済み、またmicrosoft.com(Exchange Online)からのメールもARC対応済みであり、その他のメール関連システムにおけるARC機能の実装も進んでいます。今後、ARCを利用するシステムが増えるでしょう。
- もちろん、ステータスがExperimentalなので、最終的に仕様としてInternet Standardになるかどうかは今後の動向次第です。
ARC自体には、SPFにおける修飾子やDMARCにおけるポリシー(p=)のような、検証基準を調整するパラメタはありません。
よって、ARC単独では、(送信元ドメイン側としては)試験的な段階を設けることは難しいでしょう。
ARCにより、SPF、DKIM、DMARCにおける再配送の課題を緩和するという意味では、以下のようなアプローチが考えられます。
- 仕組みについては後述します。
- 送信元ドメイン側でできることは少ないので、主にメールを受信する側のポリシー調整の観点について説明します(受信するメールには検証成功するARC署名が含まれている前提です)。
- 例えば再配送されたメールを受信する側において、SPF、DKIM、DMARCの認証が再配送の影響で失敗しても、ARCの認証が成功すればそのメールを拒否せず受信者に配送する、といった運用が可能です。
  この例の場合、ARCは再配送の課題に対する緩和策になります。もちろんメールを受信する側がDMARCよりARCの認証結果を優先するという運用判断をできること、また使用するシステムがそのような設定に対応できるものであることが前提になります。
- また、上記のようにARCの認証結果がDMARCの認証結果(結果的にそのメールを拒否したかどうか)に影響を与えた場合、それをDMARCレポートに含めることができます(例は後述)。
  送信元ドメイン側としても、そのDMARCレポートを受け取ることでARCが意図どおりに機能しているか状況分析が可能になります。
各ドメインの管理元がARC対応するきっかけとして、以下のような利用者目線の課題が考えられます(もちろんシステム管理者側が技術動向を踏まえ先手を打ってARC対応できている場合もあると思います)。
- 送信元ドメイン側としてARC対応するきっかけ
  メールの送信者が、送ったはずのメールに対して受信者から反応がなくて困っている場合(例えば、実は再配送の課題によりDMARC認証が失敗し受信者に届かなかったり、隔離されたりした)
- メールを受信する側としてARC対応するきっかけ(ARC認証結果を最終的なメール受信可否の判断材料にするかどうかの検討)
  メールの受信者が、届くはずのメールが届かなくて困っている場合(同上)
- メールを再配送する側(メーリングリストや転送の機能を持つシステム)としてARC対応するきっかけ
  上記のようにメールの送信者や受信者が困っているから解決して欲しい旨の要望等があった場合
メールの送信や中継を行うドメインが新たにARC署名するようになることで、メールが届かなくなるといった悪影響は生じにくいはずです。
影響が生じるとしたら、それはメールを受信する側のポリシー変更があった場合や、配送経路上のARC対応した他システムが側で行われるARCの検証や署名に不備がある場合が考えられます。

再配送の課題をARCにより緩和する仕組み

例えば、あるメールがメーリングリスト(ML)システムによりSubject変更されたもののDKIM署名の方は修正(署名削除や再署名等)されないまま再配送された場合、その後のDKIM認証は”fail”になります(これにより、DMARC認証も”fail”になることがあります)。しかし、MLシステムの再配送時にARC署名しておくことでARC認証として”arc=pass”となるように対処できます。
あとはメールを受信する側が、このARC認証の結果に基づいてメールを拒否しないよう判断してくれれば無事配送されます。
MLサーバソフトウェア(Mailman、Sympa)はARCの使用を推奨しています。これらのソフトウェアはARC署名が可能です。
- Mailmanマニュアル”ARC Signing”より
  
  It is highly recommended that Mailman maintainers configure ARC siging of their outgoing email.
  https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/arc_sign.html
- Sympaマニュアル”DKIM and ARC features for Sympa”より
  
  ARC is intended to fix the problems introduced by DMARC by adding signature “seals” that show the chain of servers that processed a message. Once ARC is more widely implemented, DMARC workarounds shouldn’t be needed. Once you have DKIM set up, adding ARC seals is straightforward.
  https://www.sympa.community/manual/customize/dkim-arc.html

なお、上記のMLサーバソフトウェアは、ARC対応以外に、DKIMやDMARCの認証失敗を回避するためのヘッダFrom変更等の機能を備えています。

DMARCレポートへのARC認証情報の記載例

受信する側のローカルポリシーにより、ARCの認証成功時にメールを拒否せず受け入れる判断とした場合のDMARCレポートの記載例です。
(RFC 8617の”7.2.1. DMARC Local Policy Overrides”、”7.2.2. DMARC Reporting”より)

<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
<reason>
<type>local_policy</type>
<comment>arc=pass as[2].d=d2.example as[2].s=s2
as[1].d=d1.example as[1].s=s3
remote-ip[1]=2001:DB8::1A</comment>
</reason>
</policy_evaluated>

上記のDMARCレポートは、DKIMとSPFが認証失敗(fail)しているにもかかわらず、そのメールの処理結果としては<disposition>none</disposition>(何もしない)であり、メールを受信する側がこのメールを拒否せず受け入れたことを示しています。
その理由として、<type>local_policy</type>に、認証成功(pass)したARCのChainに関する情報が記載されています。
これは、メールを受信する側がDMARC検証時、そのローカルポリシーによりARCの認証結果に基づいて判断を上書きした例(“DMARC Local Policy Overrides”)です。

ARCにおける認証情報の保持

ARCが認証情報を保持する仕組みは、メールの配送経路において、ARC対応したメールの送信者、中継者を通過するたびに、ARC署名の検証および追加が順に行われることで実現されます。
ARC署名が追加されるたびにARC-*ヘッダの中のiの値は、i=1、i=2…i=Nのように増えていきます。
ARC署名を追加する時点のAutentication-Results:ヘッダの内容がARC関連ヘッダに保持されるので、これを辿ることでそのメールの送信ドメイン認証結果の履歴を確認できます。
ARC関連ヘッダは自身に対する電子署名を含むので(ASヘッダ)、改ざんされた場合、ARC認証が失敗します。
1通のメールにつき、保持できるARC(Chain)は1つだけです。
何らかの理由でChainが壊れた場合、管理(“chain of custody”)が無効になります。再確立については今後仕様が議論されるかもしれません(ARC-USAGE)。
ARC署名時に追加されるヘッダは以下の3つです。
RFC 8617の”4.1. ARC Header Fields”に記載があります。
- ARC-Seal(AS): i=x; … cv=(ARCのChainの有効性); d=(ドメイン); b=(電子署名)
- ARC-Message-Signature(AMS): i=x; … d=(ARC内のDKIM認証対象ドメイン)… b=(電子署名)
- ARC-Authentication-Results(AAR): i=x; host.domain.com(このARC署名を追加したホストのFQDN)

ヘッダについての詳細は以下に記載します。

ARC署名時に追加されるヘッダ

以下3つのヘッダについてです。

ARC-Seal(AS)ヘッダ
ARC-Message-Signature(AMS)ヘッダ
ARC-Authentication-Results(AAR)ヘッダ

ARC署名が追加される際、AS、AMS、AARの3ヘッダにおけるiの値は同じ数が記載されます。iの値が同じこれら3つのARC-*ヘッダを、”ARCセット”と呼ぶことがあります。

ARC-Seal(AS)ヘッダ(封緘)

Chainが改ざんされないよう署名を保持する重要なヘッダです。ARC署名追加時点でChainが有効かどうかの認証結果(cvタグ)と、電子署名を含みます。b=の部分が署名です。
署名(bタグ)は、ARC 関連ヘッダを連結したデータから生成されます。署名の内容は、DKIM署名の簡易版です。
署名の作成方法は、RFC 8617の”5.1.1. Header Fields to Include in ARC-Seal Signatures”に記載があります。
おおまかには、ARC-*ヘッダ(ARCセットヘッダ)の値を正規化したものに対する署名です。
i=1のARC-*ヘッダから最新のARC-*ヘッダ(いま追加しようとしている分)までの値を全て連結したデータに対して署名されます。つまり、iの値が2以上の場合(2回目以降の署名)は、それまでのARC-*ヘッダが全て対象となります。
ARC-*ヘッダが署名作成のためのハッシュ関数に渡される順番は、ARC-Authentication-Results、ARC-Message-Signature、 ARC-Sealです。
DKIM署名との違いは以下のような点です。
- DKIMのiタグ(アドレス)でなく、i=1のようなinstance tag
- メールのBodyを対象とした署名ではないのでbhタグ無し
- Bodyの正規化無し
- Relaxed正規化のみ(RFC6376, Section 3.4.2)
- サポートされるタグは、i,a,b,d,s,t,cv
dタグは、AMSヘッダと同じドメイン名になるはずですが、RFC 8617では特にドメインの指定に対する要件は無いようです。
(“ARC places no requirements on the selectors and/or domains used for the AMS header field signatures.”、”ARC places no requirements on the selectors and/or domains used for the AS header field signatures.”)

ARC-Message-Signature(AMS)ヘッダ

ASヘッダとは別の署名です。DKIM署名とほぼ同じ形式です。
- DKIM-Signatureヘッダとの違いは、ヘッダ名が違う点、vタグが未定義である点、iタグの使い方が違う点、の3つです。
DKIMで管理されるDKIM-Signatureの内容とは関係なく、ARC単独で管理されます。
DKIM署名と同じ鍵が使われるケースはあると思いますが、ARC認証とDKIM認証の仕組み自体は相互に影響しません。

ARC-Authentication-Results(AAR)ヘッダ

ARC署名時に存在しているメールのAuthentication-Results(AR)ヘッダの内容を、このヘッダにコピーするものです。
ARC署名のたびにコピーすることで、メール配送中にARヘッダが削除、改ざんされた場合にも、AARヘッダを参照することで正しい履歴を確認できます。
Authentication-Resultsヘッダが複数ある場合、それら全ての情報をAARに含めることになっています(MUST)。
(参考：RFC 8617 “4.1.1. ARC-Authentication-Results (AAR)”より、”AAR MUST contain the combined authres-payload with all of the authentication results from within the participating ADMD”)
ただ、複数のARヘッダが存在する場合(i=2以降で、authserv-idの異なるARヘッダが存在する場合等)、どのようにAARヘッダに集約されるべきなのか不明でした。RFC 8617の”within the participating ADMD”という表現は、AARにコピーすべきARヘッダはARC署名ドメインと一致するauthserv-idのものだけに絞るという意図のようにも思います。またコピー対象とするARヘッダは直前のARC署名ドメイン分だけで十分かとも思いますが、実装や信頼性の考え方によりそうです。

ARC署名が追加されるべきタイミング

まず、理解しやすい極端なケースとして、メール送信元ドメインから外部にメール配送する最初のメールシステム(MTA,MSA)が最初のARC署名(i=1)を追加し、その後も最終的な受信者のメールボックスに配送されるまでの間、MTA等に中継されるごとに必ずARC署名を追加する方法が挙げられます。
この方法は、ARC単独で配送経路上の全ての送信者や中継者を認証できます。最初のARC署名が追加されたところから、ARCの管理(“chain of custody”)が始まるので、送信時点からのARC署名により、送信元ドメインから受信側ドメインに届くまでのChainのつながりを検証できます。
ARCの仕様上も問題はありません(ARC署名が増えると検証処理は重たくなりますが)。(参考：RFC 8617 “5.1.5. Sealing Is Always Safe”)
ただ、ARCが各ドメインに広く普及しない限り、送信時点ではARC署名が追加されないケースの方が多いでしょう。
実際、メール送信元がARC署名を追加しなくても、再配送の課題の緩和策としては機能します。再配送処理時に最初のARC署名が追加され、そこからのChainを検証できば良いという考え方です。
(参考：RFC 8617 “4.4. Chain Validation Status”の”none”の箇所)
- AARヘッダには、SPF、DKIM、DMARCの検証結果(ARヘッダの内容)を記録できるので、最初のARC署名者(メールシステム)が、それまでの送信ドメイン認証の結果をきちんとAARヘッダに記録していれば、配送経路の途中からARCが始まったとしても、送信ドメイン認証全体としては問題ないことになります(なお、最初のARC署名者は必要に応じて、それまでの送信ドメイン認証の検証を自ら行い、ARヘッダを追加するという意味も含みます)。
- 最初のARC署名者を信頼できるかどうかについては、メールを受信する側の判断になります。
ARCを有効に活用するという意味では、”信頼境界をまたぐ配送時にはARC署名を追加する”といった方針が考えられます。RFC 8617では、”Trust Boundaries(信頼境界)をまたいで認証結果を伝達する”という表現があります。
(参考：RFC 8617 “5.1.4. Broad Ability to Seal”、”5.1.5. Sealing Is Always Safe”、”7.1. Communicate Authentication Assessment across Trust Boundaries”)
上記より、ARC署名が追加され得るタイミングは以下です。信頼境界をまたぐ配送時も含みます。
- メールの送信時
  - メールを送信する時点でARC署名を追加する
  - 例：microsoft.com(Exchange Online)から送信されるメールはARC署名あり(2022年8月時点) ※ gmail.com(Gmail)は送信時でなく受信時に署名
- メーリングリスト(ML)のメンバへの配送時
  - MLシステムが受け取ったメールが、そのMLメンバに再配送される際に、ARC署名を追加する(DKIMの認証情報が無効となる場合があるため)
- メール転送による転送先への配送時
  - メール転送機能が有効なメールシステムが、受け取ったメールを、転送先に再配送する際に、ARC署名を追加する(SPFの認証情報が無効となる場合があるため)
- メールスキャンサービスの通過時
  - スパム対策システム等、メールスキャンサービスがスキャンを終えて宛先に配送する際に、ARC署名を追加する(スキャン時に加えられる変更やスキャン後の中継により、DKIMやSPFの認証情報が無効となる場合があるため)
- 多層のMTA間の配送時
  - 例えば、大規模構成におけるIPベースフィルタ層からコンテンツフィルタ層への配送の際に、ARC署名を追加する(DKIMやSPFの認証情報が無効となる場合があるため)
- あるドメイン管理元(ADMD)から別のドメイン管理元への配送時
  - “よそ”のドメインへのメール配送の際に、ARC署名を追加する(ARC署名があればメール受信者や次の中継者がChainを検証しやすい)

ARC認証により担保されること

ARCは以下の点を担保します。
DKIMの特徴に加え、ARCの特徴である認証情報が保持される仕組みが活かされます。
なおRFC 8617上の表現については、後述の”ARCにより提供できる証拠”に記載しておきます。

ARCは、そのChainを構成する各シーリングドメイン(各署名に対応するDNSレコードを保有するドメインの管理元)により以下の点を担保
- 「そのメールに含まれる個々のARCセットは、それぞれのドメインの管理元から署名することを認められたシステムによって追加されたものである」(※)
- 「それらのARCセットは、i=1～i=Nの順に追加されたものである」
- 最新のARC署名がi=Nのとき、「それ以前のARC署名(i=1～N-1)は、ARC署名者(i=N)がメールを受信した時点で存在しており、また改ざんされていない」
個々のAMSヘッダの署名(i=1～N)は、DKIMと同様に、対応するDNSレコードを保有する各ドメインの管理元により以下の点を担保
- 「メールに署名することを認められたメール送信システム、あるいはメール中継システムが、そのメールの配送経路上に存在した」(※)
- 最新のAMSヘッダの署名に関し、「そのメールにおいて、電子署名の範囲(hタグで指定したヘッダ、および、本文の全部もしくはlタグで指定した一部)については、署名した時点から改ざんされていない」

(※)”署名することを認められた”という表現は、検証に成功する署名を作成できるのは、DNSレコード上の公開鍵とペアになる秘密鍵を持つシステムのみであるという意味

ARC認証により担保されないこと

ARCでは担保されない範囲については、機会があれば、別記事にまとめるか、本記事を更新予定です。

概要としては、以下です。

ARCは、そのメールの配送経路上にARC署名しない送信者や中継者がいた場合、メールがそれらを経由したことを認証することはできません。ARC署名された分のみを認証可能です。
ARCは、メール送信時点からのメール内容(署名対象範囲)の改ざん検知を担保するものではありません。最新のARC署名分からの改ざん検知は可能です。

ARCのセキュリティに関する考慮事項

備忘用です。

(RFC 8617の”9. Security Considerations”より)

ARCにより提供できる証拠(A received message with a validated ARC Chain provides evidence (at instance N) that:)
1. the sealing domain (ARC-Seal[N] d=) emitted the message with this body,
  (ARC検証が成功すれば最新(i=N)の署名時点から本文(※)は改ざんされていない)
2. the authentication assessment reported in the ARC-Authentication-Results was determined upon receipt of the corresponding message at the sealing domain, and
  (i=N時点でのAARヘッダ内の認証結果は、そのARC署名者により決定された)
3. the preceding ARC Chain (1..N-1) (with the validation status as reported in the cv field) existed on the message that was received and assessed.
  (以前のARC署名(i=1～N-1)は、ARC署名者が受信した時点で存在していた)
  (※) 1. については、”body”はDKIM署名の対象範囲にメール本文が含まれていることを指していると思われるが、本文すべてがDKIM署名対象となっていない場合もある(lタグ)。なお、ASヘッダとしてはbodyは対象外(“4.1.3. ARC-Seal (AS)”より、”the signature of the AS header field does not cover the body of the message”)
その他
- (“9.3. Message Content Suspicion”より)
  ARC authenticates the identity of some email-handling actors. It does not make any assessment of their trustworthiness.(ARCは、メールを中継してきたシステム(MTA)を認証するが、それらの信頼性の評価は行わない)
  Even if all ARC-enabled ADMDs are trusted, ADMDs may have become compromised, may miss unsafe content, or may not properly authenticate messages.
- (“9.4. Message Sealer Suspicion”より)
  but whether or not that Sealer is a malicious actor is out of scope of the authentication mechanism.
- (“9.5. Replay Attacks”)

用語等

ARCを定義したRFC 8617の用語についてメモしておきます。

ARC-participating ADMD：
ARC対応しているADMD(管理されたAdministrative Management Domain)のこと。ドメイン管理元。
ARC対応のMTA(Mail Handler)：
通常、ARC検証者(Validator)、ARCシーラー(Sealer)の両方として機能する。
署名と封緘：
RFC 8617の”3.5. Signing vs. Sealing”を参照。
シーリングドメイン：
　あるARCセットを追加したドメイン(ADMD)