web-dev-qa-db-ja.com

DKIM：DKIMセレクターを変更せずに、DKIMで使用されるRSAキーを簡単に変更できますか？

DKIMセレクターを変更せずにDKIMで使用されるRSAキー（DNS TXT Record）を変更するだけですか？これにより問題が発生しますか？

そうでない場合、それらはDKIMセレクターの目的は何ですか？
BTW：20120113は私が20120113._domainkey.gmail.comで話しているセレクターです

securityemaildkimdmarc
2
Florian Schneider

ご覧のとおり here "。...ドメイン名にセレクターが追加され、DKIM公開鍵情報の検索に使用されます..."。

また、 Wikipedia 用語： "...受信SMTPサーバーはドメイン名とセレクターを使用してDNSルックアップを実行します[...]セレクターは簡単です署名者がいつでもキーを追加および削除できるようにする方法... "

つまり、DKIMで署名された電子メールを送信する場合は、外部のメールサーバー[〜＃〜]方法[〜＃〜]彼らはあなたのRSAキーを取得してあなたの電子メールの有効性をチェックすることができます。 RSAキーはDNSに公開されていますが、[〜＃〜] where [〜＃〜]？どのDNSクエリがそれを取得しますか？どのDNSクエリ/レコードが解決されるかをどのように知るのでしょうか？ここでセレクターが役割を果たします。example.comドメインからメールを送信していて、メールでwhateverをセレクターとして宣言すると、次のようになります。

  • 送信メールヘッダーでは、次のようにドメインと関連するセレクターを参照する必要があります。

DKIM-署名[...] d = example.com; [...] s =何でも

  • dNSで、次のように、RSAキーを公開するためのTXTレコードをwhatever._domainkey.example.comに提供する必要があります。

whatever._domainkey.example.com IN TXT "k = rsa \; t = s \; p = MIGfMA [...] AQAB"

ご覧のとおり、DNSクエリは<selector> ._ domainkey。<your_domain>の形式になっています。

これに基づいて、次のように言うことができます。

  1. rSAキーは、セレクターに影響を与えることなく交換/更新できます。明らかに、キーの一方の側（DNSで公開されているパブリックキー）を更新するときに、もう一方の側（送信メールの「署名」に使用される側）も変更することが重要です。

  2. rSAキーの更新中にセレクターを変更しないままにすると、副作用は....リモートクライアント（サーバーではなく、私が話しているのは MUA ）であり、何らかの理由で確認する必要があります古い/アーカイブされた電子メールに含まれているDKIM署名は、検証プロセスに失敗します（アーカイブされた電子メールは、DNSで公開されている公開鍵が更新された秘密鍵で署名されているため、今は違います！）。

私の経験では、DKIMの署名/検証は、検証クライアント側ではなく、電子メールの転送を対象としたプロセスであると考えていました。したがって、セレクターをそのままにしてキーを更新するのは非常に安全だと思います。

また、KEYを更新する場合は、署名コード（新しい秘密鍵を指す必要がある）とDNS（新しい公開鍵を公開するため）の両方を変更する必要があると思います。 -TXTレコードのキー）。では、セレクターも変更しないのはなぜですか（ここでも、両側で？）。[〜＃ 〜] DNSで公開された2つの[〜＃〜]セレクター。1つは古いキーを指し、もう1つは新しいキーを指します。このようにして、SMTPトランスポート中にすべてが正常になります。 、MUAは、古いセレクターに関連付けられた古いキーが引き続き使用可能であるため、古い/アーカイブされた電子メールを検証できます。

5
Damiano Verzulli

DKIMセレクターを変更せずにDKIMで使用されるRSAキー（DNS TXT Record）を変更するだけですか？これにより問題が発生しますか？

はい、あなたはできますが、正当な理由がなければそうしないことを強くお勧めします。

セレクターを再利用することが適切でない理由は次のとおりです。

  • DNSの変更は、伝播するのに時間がかかる場合があります。キー変更後にセレクターを再利用すると、キー変更直後に送信された電子メールの検証が失敗する可能性があります。
  • 送信から確認までにどれくらいの時間がかかるかわかりません。これにより、キーの変更後に古いメッセージが検証に失敗する可能性があります。遅延の考えられる理由：
  • RFCから：「新しいキーでセレクターを再利用する（たとえば、ユーザーの名前に関連付けられたキーを変更する）と、キーが無効になったために検証されなかったメッセージとメッセージの違いを区別できなくなります。これは実際に偽造されています。このため、署名者は新しいキーにセレクターを再利用することはお勧めできません。より良い戦略は、新しいキーを新しいセレクターに割り当てることです。」

DKIMセレクターの目的は何ですか？

「署名ドメインごとに複数の同時公開鍵をサポートする」。同時キーの使用例は次のとおりです。

  • 「管理上の利便性を超えて、セレクターは定期的に公開鍵をシームレスに置き換えることを可能にします。」
  • 秘密鍵を共有することなく、さまざまなエンティティが（異なるキーとセレクターを使用して）電子メールに署名できるようにします。これは次の場合に役立ちます：
    • 署名を外部組織に委任する
    • 管理上分散された組織
  • （公開鍵データ（「p = "タグ）を空のままにして）鍵を明示的に取り消すことができるようにします。

すべての引用は RFC 6376 からのものです。

3
user228011

あなたできますこれを行います。ただし、必ずしもBCPである必要はありません。

複数のセレクターを使用する理由は、キーを回転させた後も一定期間有効な状態を維持できるようにするためです。

たとえば、セレクター20120113で使用されるRSAキーを変更すると、キーが変更されたため、キューに残っていて後で配信されるメッセージはDKIMに失敗します。

理想的には、新しいキー20160106を今日公開し、それを追加のセレクターとして追加します。このようにして、両方のキーを使用するメッセージを検証できます。妥当な期間、たとえば2週間後、古いキーを非公開にすることができます。

（文字通りキー20120113._domainkey.gmail.comを意味しているわけではないと思いますか？本当にGmailキーについて話している場合は、何かを変更する前に、内部でJohn RGに話しかけてください。）

1
cmeid