kdnakt blog

hello there.

今週気になったTLS関連のニュース

TLSらじお SSL/TLS

2023年11月27日～2023年12月3日に読んだ中で気になったニュースとメモ書き（TLSらじお*1第134回の原稿）です。
全文を公開している投銭スタイルです。

[DDR&DNR for DoH/DoT/DoQ]

こちらのツイートから。

リンク先はこちら。

eng-blog.iij.ad.jp

DNSの設定は自動で降ってくるけど、DNS over HTTPS (DoH, RFC 8484) / DNS over TLS (DoT, RFC 7858) / DNS over QUIC (DoQ, RFC 9250)といった暗号化されたDNS通信の設定を自動化するための仕組みはなく手作業が必要だった。それは不便だよねってことで、自動化するための仕組みとしてDiscovery of Designated Resolvers (DDR, RFC 9462）とDiscovery of Network-designed Resolvers (DNR, RFC 9463) が2023年11月にRFC化されたとのこと。

datatracker.ietf.org

datatracker.ietf.org

DDRは従来のDNS (DNS over UDP/TCP port 53、Do53) を通じて、DNRはDHCP (Dynamic Host Configuration Protocol) またはIPv6 RA (Router Advertisement options)を通じて、設定を配信するらしい。ただ、Do53もDHCPもIPv6 RAも暗号化されないので、中間者攻撃を受ける可能性はあるとのこと。やっぱり街中のフリーWiFiとかは使わないのが無難かな...。

また、どちらもベースには、同じタイミングでRFCになった、SVCB (Service Binding) / HTTPS のDNSリソースレコード (RFC 9460)の仕組みを活用している模様。

クライアントではiOS、macOS、Chrome、DNSサーバとしてはGoogle Public DNS、ClopudflareがDDR/DNRに対応しているとのこと。DoH/DoT/DoQの端末への設定配布の道がひらけたとはいえ、Windows/Androidが未対応ではまだまだ普及には遠いような気もする。

[OpenAIのQ*とAES-192]

こちらのツイートから。

リンク先はこちら。

www.youtube.com

OpenAIのQ*と言うアルゴリズムがAES-192を解読する可能性がある、らしい。
しかし、TLSでよく出てくるのはAES-128またはAES-256。ということでこんなご意見も。

2023年に入ってから、機械学習を用いた暗号プロトコルの検証や、Kyberの電力消費量に着目したサイドチャネル攻撃など、暗号分野での機械学習・ディープラーニングの活用事例を取り上げていたので、いつかこういう日が来るかも、とは思っていたが...どうなることやら。

[前方秘匿性のある0-RTT]

こちらのツイートから。

リンク先はこちら。

https://dl.acm.org/doi/abs/10.1145/3605763.3625246

論文の本体はこちら。

前方秘匿性と訳されるForward SecrecyまたはPerfect Forward Secrecyという概念がある。TLSで利用される一時的な暗号鍵がハンドシェイクごとに異なることで、1つのハンドシェイクが破られても過去の通信は安全、ということになっている。
この論文のタイトルにあるのは「Full Forward Security」。Forwardしか合ってへんやんけ...と思ったけど、この論文とかこの論文を見るに、Forward Security = Forward Secrecyと考えてよさそう。元になったと思しきこちらの論文のアブストラクトを読んでも、やはりFullとPerfectはほぼ同じ意味と考えてよさそう。

0-RTTで前方秘匿性を達成するためのPuncturable Key Encapsulation Mechanism (PKEM)とかその具体的実装としてのBloom Filter KEM (BFKEM)が議論されていたが、この論文ではその発展系としてのTime-based BFKEMsを提案している。

0-RTTについては2023年10月にリプレイ攻撃対策としてTLS Guardという仕組みが提案されており、この先一段と複雑になっていきそう（泣）。

kdnakt.hatenablog.com

[その他のニュース]

▼CloudflareでmTLS失効確認

こちらのツイートから。

リンク先はこちら。

qiita.com

Cloudflareの認証局を使っている場合はWAFのカスタムルールで失効を条件に指定して処理できるっぽい。なるほど。

▼AWS ALBでmTLS

こちらのツイートから。

リンク先はこちら。

aws.amazon.com

これまでAWSでのmTLSはAmazon API GatewayでやるかEC2/ECSで自前実装くらいしかなかったけど、ALBでもようやくサポートされた。失効確認もちゃんとやってくれる。

▼EUの文書リークとWebの誤解

こちらのツイートから。

リンク先はこちら。

BREAKING: leaked document from MEPs lays out a delusional, paranoid joint (mis)understanding of how Web standards work, makes demands for Government, not experts, to dictate how Web works / for HTTPS backdoor #QWACs – Dropsafe

EUのお偉いさん、TLSのことあまりわかってなさそう。諜報とか、カザフスタンとやってること変わらないのでは...。
Scott Helme氏は「fundamental misunderstanding」と指摘。

▼Bulletproof TLS Newsletter #107

こちらのツイートから。

リンク先はこちら。

www.feistyduck.com

トップニュースはeIDAS 2.0の件。その他、自分が拾えてなかったニュースは以下。

RSA-2048の件は2022年末の論文と違ってただのお気持ち表明な気もするが、果たして...。

[暗認本：33 公開鍵基盤]

引き続き、ニュース以外のメインコンテンツとして『暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』を読んでいく。
今週からChapter 6 公開鍵基盤を読んでいく。

  • 互いに依存する暗号技術
    • 秘密鍵はDH鍵共有でやりとり、中間者攻撃を受けていないことをMACで検証、MACの秘密鍵を事前に検証するには...と、暗号技術は相互依存
    • 相互依存を断ち切る仕組みが必要
  • 信用の輪Web of Trust
    • 相互依存を断ち切る...例）オフラインで公開鍵を交換
    • 友達の友達は友達、と考えて信用できる公開鍵を増やす仕組み
    • その仕様の一例がOpenPGP(Pretty Good Privacy)
  • 公開鍵基盤と認証局
    • 現在のインターネットでは信用の輪ではなく公開鍵基盤Public Key Infrastructureを利用
    • 公開鍵を保証する機関＝認証局
    • 公開鍵証明書の規格＝X.509
    • 自分で正当性を証明する認証局＝ルート認証局（トラストアンカー）
  • フィンガープリント
    • フィンガープリント（拇印）：証明書のハッシュ値
    • 日本の政府認証基盤GPKI（Govermental PKI）...フィンガープリントを官報や新聞、ファックスなどで確認可能

[まとめ]

こんなツイートが。

リンク先はこちら。

eng-blog.iij.ad.jp

TLSらじおも楽しく話を聞いてもらいたいけど、原稿（このブログ）を毎週準備するだけでヒイヒイ言ってるので、テキスト読み上げソフト用に文章を調整するとかまではやってられないな...。

ランキング参加中
プログラミング

※以降に文章はありません。投銭スタイルです。

*1:TLSらじおは社内勉強会です。このブログを読み上げつつ弊社サービスの実情を語ったりします。

この続きはcodocで購入