Loading article…
DNSベースの名前付きエンティティの認証（DANE）は、トランスポート層セキュリティ（TLS）で一般的に使用されるX.509デジタル証明書を、ドメインネームシステムセキュリティ拡張（DNSSEC ）を使用してドメイン名にバインドできるようにするインターネットセキュリティプロトコルです。[1]
これは、認証局( CA )なしで TLS クライアントおよびサーバー エンティティを認証する 方法としてRFC 6698で提案されています。これは、 RFC 7671で運用および展開のガイダンスとともに更新されています。DANE のアプリケーション固有の使用法は、 SMTP についてはRFC 7672 で、サービス (SRV) レコード で DANE を使用する方法についてはRFC 7673 で定義されています。
根拠
TLS/SSL 暗号化は現在、証明機関(CA)が発行した証明書に基づいています。過去数年間[いつ? ]、いくつかの CA プロバイダーが重大なセキュリティ侵害に見舞われ、よく知られているドメインの証明書を、そのドメインを所有していない人に発行できるようになりました。侵害された CA はどのドメイン名に対しても証明書を発行できるため、多数の CA を信頼することは問題になる可能性があります。DANE を使用すると、ドメイン名の管理者は、そのドメインの TLS クライアントまたはサーバーで使用されるキーをドメイン ネーム システム (DNS) に保存して認証できます。DANE のセキュリティ モデルが機能するには、DNS レコードが DNSSEC で署名されている必要があります。
さらに、DANE を使用すると、ドメイン所有者は特定のリソースに対してどの CA が証明書を発行できるかを指定できるため、どの CA もどのドメインに対しても証明書を発行できるという問題が解決されます。
DANE は次のような類似の問題を解決します:
ただし、DANE とは異なり、これらのテクノロジはブラウザーから幅広くサポートされています。
メールの暗号化
最近まで、暗号化された電子メール転送の標準は広く実装されていませんでした。[2]電子メールの送信はセキュリティに依存しません。安全な SMTP を指定するURIスキームはありません。[3]その結果、TLS 経由で配信されるほとんどの電子メールは、日和見暗号化のみを使用します。[4] DNSSEC は認証された不在拒否を提供するため (リゾルバが特定のドメイン名が存在しないことを検証できるようにする)、DANE は、 RFC 7672で説明されているように、他の外部メカニズムを使用せずに、検証された暗号化 SMTP への段階的な移行を可能にします。DANE レコードは、送信者が TLS を使用する必要があることを示します。[3]
さらに、 DANEをS/MIME に適用するためのRFC 8162が存在し、[5] RFC 7929はOpenPGP のバインディングを標準化しています。[6]
サポート
アプリケーション
- Google ChromeはDANEをサポートしていません。これは、Google Chromeがブラウザ内で1024ビットRSAの使用を排除したいと考えているためです[7]（DNSSECは以前は1024ビットRSA署名ルートを使用していました[8] 。また、多くのゾーンは依然として1024ビットRSAで署名されていますが、最新のデフォルトは256ビットECDSAです[9]）。Adam Langleyによると、コードは[10]書かれており、現在Chromeには含まれていませんが[11]、アドオン形式で引き続き利用可能です。[12]
- Mozilla FirefoxはDANEをサポートしていません。この件に関するチケットの反応（「この機能を実装する予定はありません」）に基づくと、DNSSECとDANEは現在Mozilla開発者によってFirefoxの範囲外とみなされています。[13] [14]アドオンサポートはFirefox 56（最終更新2016 [15] ）まで利用可能でしたが、現在は存在しません。より最近の、より制限の多いFirefox拡張APIでは実装できなくなりました。[16]
- GNU Privacy Guard OpenPGP DANE (--auto-key-locate) 経由でキーを取得できるようにします。新しいオプション --export-options export-dane。(バージョン 2.1.14) [17]
- Cheogram AndroidではDANE経由での検証が可能で、DANEが使用されたかどうかのステータスが表示されます[18]
サーバー
サービス
図書館
TLSA RR
サービスの TLSA RR (リソース レコード) は、特定の TCP または UDP ポートのサービスに証明書の制約を適用することを指定する DNS 名にあります。TLSA RR の少なくとも 1 つは、指定されたアドレスのサービスによって提供される証明書の検証 (パス) を提供する必要があります。
すべてのプロトコルが共通名の一致を同じ方法で処理するわけではありません。HTTP では、TLSA の有効性に関係なく、サービスによって提供される X.509 証明書の共通名が一致する必要があります。SMTP では、証明書の使用値が 3 (DANE-EE) の場合、共通名の一致は必要ありませんが、それ以外の場合は共通名の一致が必要です。使用しているプロトコルに特定の指示があるかどうかを確認することが重要です。
RRデータフィールド
RR 自体には 4 つのデータ フィールドがあり、ドメイン所有者が提供する検証のレベルを説明します。
- 証明書の使用フィールド
- セレクタフィールド
- 一致するタイプフィールド
- 証明書関連データ
例えば_25._tcp.somehost.example.com. TLSA 3 1 1 0123456789ABCDEF
証明書の使用
DNS RR の TLSA テキストの後の最初のフィールドは、証明書の検証方法を指定します。
- 値 0 は、一般にCA 制約(および PKIX-TA) と呼ばれるものです。TLS を確立するときに提供される証明書は、リストされているルート CA またはその中間 CA の 1 つによって発行され、検証を行うアプリケーションによってすでに信頼されているルート CA への有効な証明書パスを持つ必要があります。レコードは中間 CA を指すだけの場合もあり、その場合、このサービスの証明書はこの CA 経由で提供される必要がありますが、信頼されたルート CA へのチェーン全体は依然として有効である必要があります。[a]
- 値 1 は、一般にサービス証明書制約(および PKIX-EE) と呼ばれるものです。使用される証明書は TLSA レコードと一致する必要があり、信頼されたルート CA へのPKIX証明書パス検証に合格する必要もあります。
- 値 2 は、一般にトラスト アンカー アサーション(および DANE-TA)と呼ばれるものです。TLSA レコードは、サービスで使用されている証明書のルート CA または中間 CA の 1 つの証明書と一致します。証明書パスは一致する証明書まで有効である必要がありますが、信頼できるルート CA は必要ありません。
- 値 3 は、一般にドメイン発行証明書(および DANE-EE) と呼ばれるものです。TLSA レコードは、使用される証明書自体と一致します。使用される証明書は、他の当事者によって署名される必要はありません。これは、自己署名証明書の場合に役立ちますが、検証者が信頼できるルート証明書のリストを持っていない場合にも役立ちます。
セレクタ
サービスに接続して証明書を受信すると、セレクター フィールドで証明書のどの部分をチェックするかを指定します。
- 値 0 は、照合のために証明書全体を選択することを意味します。
- 値が 1 の場合、証明書の照合に公開キーのみを選択します。公開キーは一意である可能性が高いため、多くの場合、公開キーの照合で十分です。
マッチングタイプ
- タイプ 0 は、選択された情報全体が証明書関連付けデータに存在することを意味します。
- タイプ 1 は、選択したデータの SHA-256 ハッシュを実行することを意味します。
- タイプ 2 は、選択したデータの SHA-512 ハッシュを実行することを意味します。
証明書関連データ
他のフィールドの設定に基づいて照合される実際のデータ。これは 16 進データの長い「テキスト文字列」です。
例
www.ietf.orgの TLSA レコードは、CA を無視して、提供された証明書の公開キーの SHA-256 ハッシュをチェックするように指定します。
_443._tcp.www.ietf.org. TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6
彼らのメールサービスにはまったく同じ証明書と TLSA があります。
ietf.org。MX 0 mail.ietf.org。_25._tcp.mail.ietf.org。TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6
最後に、次の例は他の例と同じことを行いますが、証明書全体に対してハッシュ計算を行います。
_25._tcp.mail.alice.example. TLSA 3 0 1 AB9BEB9919729F3239AF08214C1EF6CCA52D2DBAE788BB5BE834C13911292ED9
標準
- RFC 6394 名前付きエンティティの DNS ベース認証のユースケースと要件 (DANE)
- RFC 6698 DNS ベースの名前付きエンティティの認証 (DANE) トランスポート層セキュリティ (TLS) プロトコル: TLSA
- RFC 7218 名前付きエンティティの DNS ベース認証 (DANE) に関する会話を簡素化するための頭字語の追加
- RFC 7671 DNS ベースの名前付きエンティティ認証 (DANE) プロトコル: 更新と運用ガイダンス
- RFC 7672 SMTP セキュリティ、DNS ベースの名前付きエンティティ認証 (DANE) トランスポート層セキュリティ (TLS) 経由
- RFC 7673 SRV レコードを使用した DNS ベースの名前付きエンティティ認証 (DANE) TLSA レコードの使用
- RFC 7929 OpenPGP の DNS ベース名前付きエンティティ認証 (DANE) バインディング
- RFC 4255 DNS を使用してセキュア シェル (SSH) キー フィンガープリントを安全に公開する
- RFC 8162 セキュア DNS を使用して S/MIME のドメイン名に証明書を関連付ける
- 草案：DANEセマンティクスとIPsecによる日和見暗号化：IPSECA [27]
参照
注記
- ^ これが役立つ珍しい例としては、ルート CA を完全に信頼していないが、多くのアプリケーションが依然としてルート CA を使用しており、中間 CA の特定のものを信頼している場合、中間 CA をリストすると完全な信頼パス検証が得られる、というものがあります。
参考文献
- ^ Samad、Muhammad Alif Adha Bin (2011 年 10 月 6 日)。「DANE: DNSSEC を使用して TLS 認証を次のレベルに引き上げる」。IETF Journal。2018年8 月 5 日閲覧。
- ^ 「Postfix TLSサポート - セキュアなサーバー証明書の検証」。Postfix.org 。 2015年12月30日閲覧。
- ^ ab Dukhovni; Hardaker (2013-07-28). DANE for SMTP (PDF) . IETF 87 Proceedings. IETF.
- ^ Filippo Valsorda (2015-03-31). 「SMTP 暗号化の悲惨な現状」 。2015年 12 月 30 日閲覧。
- ^ Hoffman, P. (2017 年 5 月). 「S/MIME 用のドメイン名に証明書を関連付けるためのセキュア DNS の使用」。IETF . doi : 10.17487/RFC8162 . RFC 8162. 2022 年 3 月 30 日閲覧。
- ^ Wouters , P. (2016 年 8 月). OpenPGP の DNS ベース認証 (DANE) バインディング。IETF。doi : 10.17487/RFC7929。RFC 7929。2016年9 月 14日閲覧。
- ^ Langley, Adam (2015-01-17). 「ImperialViolet - ブラウザーで DANE を使用しない理由」www.imperialviolet.org . 2017-03-24閲覧。[自費出版ソース]
- ^ Duane Wessels、Verisign (2016-05-16)。「ルートゾーンの強度ゾーン署名キーの強化」Verisign.com 。 2016年12月29日閲覧。
- ^ 「Bind9 DNSSEC ガイド」. bind9.readthedocs.io . 2021年8月22日閲覧。
- ^ Adam Langley (2012-10-20). 「DANE ホッチキス留め証明書」. ImperialViolet . 2014-04-16閲覧。[自費出版ソース]
- ^ Adam Langley (2011-06-16). 「Chrome での DNSSEC 認証 HTTPS」. ImperialViolet . 2014-04-16閲覧。[自費出版ソース]
- ^ Google Chrome に DNSSEC サポートを追加する方法
- ^ 「672600 - 証明書チェーンの検証で TLS ハンドシェイクに組み込まれた DNSSEC/DANE チェーンを使用する」。
- ^ 「1479423 - DNSSEC/DANE/TLSA 検証のサポート」。
- ^ Weber, Johannes (2016年10月25日). 「DANE/TLSAの使い方」Weberblog.net。
- ^ DNSSEC/TLSA バリデーター
- ^ 「GnuPG - リリースノート」. gnupg.org. 2021年6月12日. 2021年8月27日閲覧。[自費出版ソース]
- ^ 「cheogram-android 2.13.0-1」。2021年2月11日閲覧。
- ^ 「Postfix TLS サポート - DANE」。Postfix.org。2014年 4 月 16 日閲覧。
- ^ 「PowerMTA 5.0 リリース」。SparkPost.com 。 2020年4月26日閲覧。
- ^ 「Exim 4.91 仕様: TLS/SSL を使用した暗号化 SMTP 接続 / 15. DANE」。exim.org。2018年 7 月 5 日閲覧。
- ^ "mod_s2s_auth_dane_in". prosody.im . 2024年2月11日閲覧。
- ^ Scaturro, Michael (2014-08-24). 「ドイツ流にメールを守ろう」The Guardian . 2018-04-29閲覧。
... 昨年 5 月、[Posteo] は、自社のサーバー上で DNS ベースの名前付きエンティティ認証 (Dane) を採用した世界初のメール プロバイダーになりました。 ...
- ^ DANE Everywhere?! Let's Make the Internet a Private Place Again、tutanota.de 、2015年12月17日閲覧[自費出版ソース]
- ^ Richard Levitte (2016-01-07). 「DANE CHANGES」. GitHub . 2016-01-13閲覧。[自費出版ソース]
- ^ 「DANE (DNSSEC) を使用した証明書の検証」Gnu.org。[自費出版ソース]
- ^ Osterweil, Eric; Wiley, Glen; Okubo, Tomofumi; Lavu, Ramana; Mohaisen, Aziz (2015 年 7 月 6 日)。「DANE セマンティクスと IPsec による Opportunistic Encryption: IPSECA」。インターネット エンジニアリング タスク フォース。
外部リンク
- DNSSECは不要 - DNSSECに反対
- DNSSEC 賛成 - 「DNSSEC 反対」の論点に対する反論
- DANE テスト サイトのリスト
- メールサーバーの DNSSEC と DANE サポートを確認するオンライン ツール
- ハウツーやツールへのリンクを含むイラスト付きDANEアドボカシー