JPNIC News & Views vol.1747【臨時号】第106回IETF報告 [第4弾] メール関連報告

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    __
    /Ｐ▲        ◆ JPNIC News & Views vol.1747【臨時号】2020.1.29 ◆
  _/ＮＩＣ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
---------- PR --------------------------------------------------------
■■ IPv6 Summit in TSU 2020 & IPv6ハンズオンセミナー ＠三重県津市■■
□┏━━━━━━━━━━━━━━━━━━━━┓ 2月6日(木)/7日(金) □□
■┃1日目:座学セミナー & IPv6 Summit in TSU ┃ 主催:IAjapan/JPNIC ■■
□┃2日目:ハンズオンセミナー                ┗━━━━━━━━━┓□□
■┃→→ https://www.nic.ad.jp/ja/topics/2019/20191223-01.html  ┃■■
----------------------------------------------------------------------
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.1747 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

vol.1738より、2019年11月下旬にシンガポールで開催された第106回IETFミー
ティングのレポートを、連載にてお届けしています。最終回となる本号では、
電子メールに関する技術仕様の動向についてご紹介します。

なお、これまでに発行した第106回IETFの各報告については、下記のURLから
バックナンバーをご覧ください。

  □第106回IETF報告
    ○[第1弾] 全体会議報告 (vol.1738)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2020/vol1738.html
    ○[第2弾] トランスポートエリア関連報告
              ～Web Packing BoFとWebTransport BoF～ (vol.1739)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2020/vol1739.html
    ○[第3弾] DDoS対策(DOTS WG)関連報告 (vol.1744)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2020/vol1744.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第106回IETF報告 [第4弾]  メール関連報告
                         株式会社インターネットイニシアティブ 櫻庭秀次
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

本稿では、2019年11月下旬にシンガポールで開催されたIETF 106ミーティン
グを含め、最近のメールに関する技術仕様の動向についてご紹介します。迷
惑メールの問題や、フィッシング、BEC (Business Email Compromise)等のセ
キュリティ脅威を背景に、メールの送信元を確認する送信ドメイン認証技術
や、メールの配送経路の暗号化に関わる技術仕様について、IETFでは議論さ
れてきました。


■ 送信ドメイン認証技術とdmarc WG

IETFでは、当初SenderIDとして仕様の統合を目指したSPF (Sender Policy
Framework)が、改定後にExperimental RFCからStandards TrackのRFC 7208と
なりました。SPFは、直近の送信元IPアドレスが正しい送信元であるかどうか
を認証しますが、メールの配送経路に依存しない、電子署名技術を認証に利
用するDKIM (DomainKeys Identified Mail)が、STD 76 (RFC 6376)となりま
した。SPFは、送信側の導入の容易さから、普及率が高いという特徴がありま
す。DKIMは、メール転送時に認証が失敗するSPFの補完として、またメッセー
ジ内容の改ざんを検知できる堅牢な技術として、普及が進みつつあります。

SPFとDKIMは、それぞれ独立した技術仕様ですが、これらの認証結果を利用す
る、統合的なドメイン認証技術がDMARC (Domain-based Message
Authentication, Reporting, and Conformance)であり、RFC 7489として標準
化されています。DMARCは、送信元を認証する仕組み以外にも、以下の特徴が
あります。

- メール受信者が送信者情報と判断する、ヘッダ上のFromのドメインを認証
- メール受信側から認証結果や受信処理結果に関する情報を、送信ドメイン
  側に通知するレポート機能(DMARCレポート)
- ドメイン管理側が、認証が失敗したメールの取り扱いを示すポリシーをDNS
  上に設定(DMARCレコード)

SPFとDMARC、さらにDMARCを利用したとしても、現在の一般的なメール利用形
態の中には、送信ドメイン認証に対応した正規のメールが、認証失敗する場
合が残されています。メーリングリストなど、メールを再配送するようなケー
スの一部です。こうした課題にも対応するため、メールの受信側だけが送信
元を認証するという仕組みから、メール転送やメーリングリストなどそれぞ
れの再配送元でも認証を行い、それらの結果を示すヘッダを含めて再署名を
行うことで認証のチェーンを構成するための仕様が、dmarc WGで検討され、
ARC (Authenticated Received Chain, RFC 8617)となりました。

現在もdmarc WGでは、組織ドメインを判断する仕組みとしてpublic suffix
listに依存しない仕様や、DMARCをよりよく使うための改善などを検討してい
ます。しかしながら、今回のIETF 106 meetingでは、dmarc WGは開催されま
せんでした。


■ uta WG

メールなどのアプリケーションで、通信相手を認証したり通信内容を暗号化
したりするためにTLSを利用し、セキュリティを高めたいと考える機運が高
まっています。しかしながら、例えばメールの配送プロトコルであるSMTPで
は、メールの送信側がTLS (STARTTLS)に対応していても、受信側で対応して
いなかったり、TLSのネゴシエーションが失敗したりした場合には、メッセー
ジが平文で送信されます。本来のメール送受信側それぞれで対応できる場合
でも、何らかの方法により悪意のある中間者が介在した場合は、容易にTLSを
無効化できてしまう、ダウングレード問題が課題として存在していました。
こうしたアプリケーション上のTLSについて、仕様を整備していくためのWGが
uta (Using TLS in Applications)です。

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461)では、受信側の
ドメインが、あらかじめTLS (STARTTLS)に対応しているかを、DNSとHTTPSを
利用してポリシーとして伝えたり、TLSのネゴシエーションが失敗したりした
場合に、メール送信を(平文で)継続するかを示すことができます。

また、こうしたTLSの実施状況を、メールの送信側から受信側へレポートする
TLSRPT (SMTP TLS Reporting, RFC 8460)も仕様化されました。これらの仕様
により、メール配送時のTLS利用がより進むことが期待されます。


■ IETF 106 meeting

今回のシンガポールでのmeetingでは、これらのWG会合は開催されず、メール
関連ではjmap (JSON Mail Access Protocol) WGのみが開催されました。JMAP
は、メールやカレンダーデータ、コンタクトアドレスなどを、JSON
(JavaScript Object Notation)形式で、サーバとクライアントの間で同期す
るためのプロトコルです。既にメールの基本的な仕組みは、RFC 8620とRFC
8621となっていますが、今回の会合では、カレンダーデータについて検討が
行われました。カレンダーデータについては、calext (Calendaring
Extensions) WGでも議論されており、双方とも協調した作業が行われていま
す。


■ 終わりに

メール関連では、送信ドメイン認証技術や暗号化関連以外にも、IETF 104
meetingでBoFが開催された、BIMI (Brand Indicators for Message
Identification)も検討されています。まだWGとはなっていませんが、個人的
には、メールに関連するアプリケーション的な要素と、セキュリティ的な側
面の検討が必要な、興味位深い議論となるのではと考えています。メールは
基盤技術であり、重要なコミュニケーションツールのため、最近ではセキュ
リティ的な対策に関連する仕様の検討が多いのですが、メールをアプリケー
ションとして、より便利にするための議論があっても良いはずです。

今後もメールが有益なツールとして利用できるように、関連する議論に関わっ
ていきたいと考えています。


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
      わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
                  ◇              ◇              ◇
            メールマガジン以外でも、情報を発信しています！
             JPNICブログ  https://blog.nic.ad.jp/
                 Twitter  https://twitter.com/JPNIC_info
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃ https://feedback.nic.ad.jp/1747/e7a3726ce1bd71187716c4c22213afd7 ┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃ https://feedback.nic.ad.jp/1747/1e28900c33de3e8bc7394ef7ad09e899 ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  JPNICの活動はJPNIC会員によって支えられています  ■■■■■
  :::::  会員リスト  ::::: https://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト :::: https://www.nic.ad.jp/member/ (PASSWORD有)
□┓ ━━━  N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛          お問い合わせは  jpnic-news@nic.ad.jp  まで          ┗┛
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 JPNIC News & Views vol.1747 【臨時号】

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          101-0047 東京都千代田区内神田3-6-2 アーバンネット神田ビル4F
 ＠ 問い合わせ先 jpnic-news@nic.ad.jp
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
            本メールを転載・複製・再配布・引用される際には
        https://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
   ◇ JPNIC Webにも掲載していますので、情報共有にご活用ください ◇
登録・削除・変更   https://www.nic.ad.jp/ja/mailmagazine/
バックナンバー     https://www.nic.ad.jp/ja/mailmagazine/backnumber/
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■     News & ViewsはRSS経由でも配信しています！    ■■■■■
::::: https://www.nic.ad.jp/ja/mailmagazine/backnumber/index.xml :::::
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

■■◆                          ＠ Japan Network Information Center
■■◆                                     ＠  https://www.nic.ad.jp/
■■

Copyright(C), 2020 Japan Network Information Center
このページを評価してください
