セコムIS研究所
島岡 政基
DNS Summer Days 2012

DANE update1

Sep 1, 2012

自己紹介

• 2006年頃までIETF/PKIX WG中心に活動

Patrick
Guillemin

SteveBellovin

JNSA
安田氏

富士ゼ稲田氏IPA宮川氏TimPolk

私Paul
Hoffman

DNS Summer Days 2012

• 最近はPKI以外にもShibboleth, OpenIDなど• 最近は段々技術からポリシなどメタなレイヤへ。。。

Sep 1, 2012

• 2年目まではインターネット関連サービスシステム構築のSE• 2000年以降はGPKI、AsiaPKI、UPKIと10年以上PKIどっぷり

2

• 概要
• TLS認証にCAの代わりにDNSSECを活用する技術• ドメイン名に証明書(またはそのハッシュ)を関連づけるリソースレコードとしてTLSAレコードを定義。

• History• 2010年12月に-00公開。DANE WGの前身、KIDNS ML時代。
• 2012年8月、-23からRFC 6698として公開。1年半は順調な部類。

DNS Summer Days 2012

• RFC 6698: The DNS-Based Authentication of Named Entities (DANE)Transport Layer Security (TLS) Protocol: TLSA

Sep 1, 2012

dane-protocol(通称TLSA)

4

TLSAレコード

0: Exact match
1: SHA-256
2: SHA-512

Selector 0: Full certificate
1: subjectPublicKeyInfoCert.
Usage

0: CA constraint (中間CA証明書でもok)
1: Service certificate constraint (CAから発行されたサーバ証明書)
2: Trust anchor assertion (ルートCA証明書)
3: Domain-issued certificate (自己署名証明書ok)
1: 認証パスの検証必須
3: 認証パスの検証不要

DNS Summer Days 2012

Matching TypeSep 1, 2012_443._tcp.www.example.com. IN TLSA (0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
7983a1d16e8a410e4561cb106618e971 )5Running code

• SWEDE• TLSAレコードの作成・検証ツール• Pythonベース• https://github.com/pieterlexis/swede• 実装してない機能も沢山あります。

• DANE for NSS• NSS(Mozilla)に対するパッチ• https://mattmccutchen.net/cryptid/#nss-dane• SSL_AuthCertificateでTLSA RRsetを取得する• PoCなので実運用には無理あり

DNS Summer Days 2012

• Datatracker→IESG Writeups• https://datatracker.ietf.org/doc/draft-ietf-daneprotocol/writeup/

Sep 1, 2012

• RFC化におけるrunning code

6

DANE WGの動向• リチャーターに関する議論• 今後出てくることが予想されるであろう各アプリケーションへの実装方式をどこまでDANE WGで扱うべきか?
• 原則論(General purpose edition)を示すべきか?

DNS Summer Days 2012

• smtp-04, mua-00, smime-03, (xmpp-02)• TLSプロトコルの中でTLSAレコードを使うための手順を定義している(smtp, mua)Sep 1, 2012

• アプリケーションプロトコルへの実装• 詳しくはJPRS森下さんの報告記事にて！
• 第84回IETF Meeting報告（1） ～DANEの動向に関する話題～• http://jpinfo.jp/event/2012/0831IETF.html

7• パブリック証明書を入手して使う• お金かかる！

• 中間者攻撃のリスクを無視できる範囲で利用する• 判断難しい！
• 責任取りたくない！
• 説明難しい！

DNS Summer Days 2012

オレオレ証明書は中間者攻撃対策が不十分∵TTP (Trusted Third-Party)不在

Sep 1, 2012

中間者攻撃とオレオレ証明書問題• 証明書を利用者に配付・インストールしてもらう• 面倒！
• (相手によっては)頼みづらい！
• 結局理由を説明しないといけない！

8

TLSAで何が変わる??

• 認証局なしで安全な暗号化通信を実現できる
TLSAレコードに登録

TLSAレコードを取得
DNSSECサーバと通信してるつもりと通信してるつもり！？証明書違うじゃん！

www.example.comの証明書です(嘘の証明書はこれです

DNS Summer Days 2012

• DNSSECで安全にサーバ証明書を配付できる• 中間者攻撃の脅威がない→つまり難しい説明不要！

Sep 1, 2012

• 自己署名サーバ証明書が使いやすくなる

9認証局が提供しているのは…
• 申請者：私有鍵を用いて署名生成。公開鍵とともに認証局に送付。
• 認証局：公開鍵で署名検証。
• PKCS#10という証明書発行要求のデータフォーマットを用いる。

• Domain validation：当該ホスト(管理者)からの申請であること• やり方は色々。
• 例1： 予め登録済のホスト管理者メールアドレスに連絡。
• 例2: 予め登録済の権限者経由でのみ申請を受け付ける。

• サーバ証明書の失効• 漏洩した鍵の不正利用を防ぐ• なりすまし、盗聴、復号解読など

DNS Summer Days 2012

• Proof of Possession：公開鍵に紐づく私有鍵を所持していること

Sep 1, 2012

• サーバ証明書発行時の確認作業

こうした一連の作業について、CPSによって透明性を確保している
10

TLSAの課題?
• (Web)サーバのDNSサーバがDNSSECを導入していること。
• ラストツーマイル問題??

• 証明書失効ができない• 私有鍵漏洩したら盗聴される危険性• ただしなりすましリスクは低い?

• DNS管理者の負担

DNS Summer Days 2012

• DNSSECのラストワンマイル問題

Sep 1, 2012

• 利用者のDNSSECサポートが大前提。

• TLSAレコードの登録・更新• アプリケーションプロトコル増えれば責任も、、、
11

参考資料
• RFC 6698
• https://tools.ietf.org/html/rfc6698• JPRS IETF Meeting報告• 第83回IETF Meeting報告 ～DNS関連の話題を中心に～• http://jpinfo.jp/event/2012/0425IETF.html• 第84回IETF Meeting報告（1）～DANEの動向に関する話題～• http://jpinfo.jp/event/2012/0831IETF.html

DNS Summer Days 2012

• https://tools.ietf.org/wg/dane/

Sep 1, 2012

• IETF/DANE WG• TLSとDNSSEC• DNSSEC 2012 スプリングフォーラム資料• http://dnssec.jp/?page_id=913

12