━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ __ /P▲ ◆ JPNIC News & Views vol.1747【臨時号】2020.1.29 ◆ _/NIC ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ---------- 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