QUICやTLS通信のデバッグを行うために、TLS実装が通信に用いたシークレットをファイルに出力することがあります。多くの実装は SSLKEYLOGFILE という形式で出力することが一般的になっています。このファイルをWiresharkなどに食べさせることで該当通信の復号が行なえます。 たとえば、QUICは以前書いた手順で復号できます。 asnokaze.hatenablog.com SSLKEYLOGFILE のファイル形式は、NSSのドキュメント(URL)で見ることが出来ますが ちゃんと SSLKEYLOGFILE を仕様化するために「The SSLKEYLOGFILE Format for TLS」という提案がIETFに提出されています。 SSLKEYLOGFILEの中身 例えば OpenSSLでSSLKEYLOGFILE を出力すると次のとおりになる # SSL/TLS secr

認証付き暗号 "Authenticated Encryption with Associated Data (AEAD)" の利用上の制限について、「Usage Limits on AEAD Algorithms」というドキュメントが公開されている。 このドキュメントでは機密性と完全性を一定以上に保つために、一つの鍵の利用上限についてまとめています。 「RFC 8446 TLS1.3」を読んだことがあれば、その仕様の中で「5.5. Limits on Key Usage」の章で、一つの鍵でAES-GCMでレコードを暗号化していい上限値を規定しているのをご存知かもしれません。また、同様の記述がQUICの仕様(URL)にも記述されています。（上限に達する前に鍵更新が行われます） このように暗号の解析についてはいくつかの論文に分散しているため、プロトコルの標準化を行うために各仕様から参照できるよ

ユーザに対して、そのユーザ名のサブドメインやメールアドレスを払い出すWebサービスがあります。 しかし、特定のサブドメインやメールアドレスは特別な用途で使われているものもあります。そのようなサブドメインやメールアドレスを一般ユーザに払い出してしまうと危険です。 現在、IETFでは仕様上利用用途が決められている、それらのラベルをとりまとめる「Dangerous Labels in DNS and E-mail」というdraftが提出されています。 今回はそれを眺めていきます。 （あくまでIETFの取り組みであり、仕様上定義されているものをとりまとめています。クラウドサービスや特定ベンダーで特別利用しているものは現在含まれていません。） サブドメイン ここでとりあげるサブドメインは、利用用途が決まってるため一般ユーザに払い出すべきではありません。(例: mta-sts.example.com)

新しいHTTPメソッドを定義する「The HTTP QUERY Method」という提案仕様が議論されています。 もともとは、SEARCHメソッドという呼び名が候補としてあげられていましたが、長い議論ののち、一旦QUERYと呼ぶ方向となっております。最終的なFixについては、この draft 02の公開とともに改めてコンセンサスを求めた後に行われます。 QUERYメソッド 「GETリクエストにボディを付けたいという」という質問は長らく有りました。しかし、GETやHEADリクエストでボディをつけることは非推奨となっています (参考URL)。 そのような要望のなかで、リクエストでボディを含められる冪等性の保証された新しいHTTPメソッドが検討されました。それがQUERYメソッドです。冪等性があるため、ブラウザやProxyは自動でリトライすることができます。(なお、POSTはセマンティクス上冪等