追記 20170510
draft-01 より、hxxpsも予約されました
「The "hxxp" and "hxxps" URI Schemes」
hxxp URIを定義する「The "hxxp" URI Scheme」という仕様が提案されています。
hxxp://... は、例えばセキュリティの話をする際にURLがリンクとして解釈されたり、ブラウザやメーラによって解釈・処理されないようにするために使用されています。
この仕様では、将来的にアプリケーションでこのhxxp:// を使用できないように予約します。
hxxp URIによって参照されるリソースは、アプリケーション等によって自動的にパース・処理されないことを意味します。
このリソースは、セキュリティの専門家によって利用されなければなりません(MUST)。
また、アプリケーション開発者はhxxpスキームURIをHTMLのアンカーやタグで使用しないように推奨されています。
追記 10190510
関連して、このような動きもあります。
Cookie の SameSite=Lax をデフォルトにする提案仕様 - ASnoKaze blog
HTTPのCookieの仕様は RFC 6265 - HTTP State Management Mechanism で定義されております。
2015年頃より、IETFのHTTPbisワーキンググループではCookieのセキュリティを向上させる目的で拡張仕様が3つほど議論されていました。
動作確認用のページもあるようです http://rfc6265.biz/tests/
それぞれの拡張仕様はChromeとFirefoxで実装が進められており、先月シカゴで行われたIETF98では各拡張仕様の提案者でもあるGoogleのMike West氏よりそれぞれの使用状況についてのフィードバックがありました。短いですが議事録より確認できます。
上記3つの拡張仕様はそれぞれを標準化するのではなく、RFC 6265の改訂版である6265bisに組み込む形で標準化されることがMLで話されておりましたが(URL)、4/25に rfc6265bisのdraft01 が提出されました。
RFC 6265からの主な変更点は下記のとおりです
Same-site cookiesについては、AuthorがML上で言及しているとおり(URL)、もう少し作業があるようだが、7月に行われるIETF98までに議論すべきものが出て来る形になりそうだ。
追記 20170510
この提案仕様は、draft01でauthor自ら廃案とされました。
昨日の「DNS over QUICの提案仕様が出た」引き続きDNS関連の記事
近年注目されている、"DNS over HTTP"は例えば「DNS-over-HTTPS」としてGoogleが提供していたり、IETF97でもdnsoverhttp BarBof(有志によるミーティング)も行われ課題についても議論がされています(議事録URL)。
もちろん仕様としても提案されており、以下などがあります
(IP + Portを見て)外とのDNSの通信がブロックされたりする環境があるようで、これらはDNSをHTTP上で行おうというものです。
さらに先日、以下の2つのドラフトが提出されています
これらは、Webサービスとの通信といった既存のHTTP/2, QUICコネクション上でさらにDNSのメッセージもやりとり出来るようにする拡張仕様である。サーバ認証も行って確立した暗号路で改ざんを防ぎ、既存のコネクションを使うことでDNS通信がブロックされないようにする。
同じ著者によってHTTP/2とQUICのコネクションを利用するものが別々に提案されているが基本的には、新しくストリームをオープンし、その上でDNSのリクエストとレスポンスを行う。
新しくDNSフレーム
+---------------+ |Pad Length? (8)| +---------------+-----------------------------------------------+ | DNS message (*) ... +---------------------------------------------------------------+ | Padding (*) ... +---------------------------------------------------------------+
既存のコネクションを利用しているため、DNSの問い合わせに応答するのはすでに接続しているサーバとなる。もちろんこの拡張に対応しているとは限らないため、下記のようにする。
拡張フレームは対応していない場合は無視されるので、上記拡張hルエームで問い合わせたいクエリ送信する。
もしくはexample.comなどのクエリを問い合わせし、対応していることを確認してから本来確認したクエリを送信するということも出来る。
まだまだエラーハンドリングや、Settingsを使うか、ストリームの遷移・マッピングなど細かい所は決まってはいないが、IETFでのフィードバックにもあった一つのQUICコネクション上で複数のアプリケーションプロトコルという仕組みの提案として面白いと思う。
また、SPDY/4で追加機能として挙げられてはいた「Server push of DNS records」というものを思い出した。
(https://www.chromium.org/spdy/spdy-protocol)
2020/04/28 追記
仕様の名前が少々変わりましたが、WG Draftとなり作業は引き続き続けられています。
「Specification of DNS over Dedicated QUIC Connections」
IETFでQUICの標準化が活発に行われており、トランスポート・TLS・HTTP各レイヤのドラフト仕様の改定が進められております。
標準化を行うにあたって当初より、DNSのトランスポートとしてQUICを使用したいという話題は出ていましたが、QUICワーキンググループのチャーターでは、まずはQUICのアプリケーションレイヤとしてHTTPの標準化を行ってから他のアプリケーションプロトコルについて進める旨書かれている。
とはいえDNS over QUICをやりたい人はいるようで、4/11にインターネットドラフトが出されている。共著者にQUICについてよく発表しているGoogleの方や、SalesforceやFastlyの人もいる。
「Specification of DNS over QUIC」として書かれている。
主な目標として下記があげれている
上記の目標のために、想定する通信はスタブリゾルバからリカーシブルリゾルバの通信を想定し、ゾーン転送は考慮しない。中間装置によるブロックを考慮しないことが挙げられている。
HTTP同様DNSでもレイテンシを小さくするため、0-RTTセッション再開、ロスリカバリのサポート、マルチストリームでヘッドオブラインブロッキングの回避の機能について言及がある。
ALPNで使用する識別子として、"qd"を使用する。HTTP同様、ハイフン付きでドラフトバージョンを指定する
具体的なポート番号はTBDとなっているが、DNS over UDPやDNS over DTLSとの混用を避けるため53, 853の使用は避けるようだ。サーバはそのポートでリッスンし、クライアントはそのポートにつなぎに行く。
各ストリームがDNSのリクエスト/レスポンスに相当する。クライアントから開始するストリームは、3, 5, ... と続く。
DNS Push NotificationsのようなサーバからPUSHメッセージを送ることも可能で、サーバから開始するストリームは2, 4, ...となる。クライアントはそのストリーム上で応答を返す。
DNS Privacy Considerations(RFC7626)で言及されていることは、DSN over TLSの場合と変わらないが、0RTT通信と、セッション再開について言及がある。
観測者は0-RTTを利用した問い合わせを再送することができます。これによりリカーシブルリゾルバから権威リゾルバへのクエリをトリガできます。リカーシブルリゾルバの振る舞いを観測できる場合は、0-RTTの問い合わせを再送させることができもともとの問い合わせを推測リスクが高まります。デフォルトでは無効にしとくことが好ましい。
QUICではIPアドレスが変わってもセッションを維持できるため、それらが同じクライアントだと識別可能です。セッション再開や長いセッションはパフォーマンス上有用だが、クライアントは考慮スべき。
QUICの各仕様のdraft-02が出た一方で、マルチパスQUICに関する考察ドラフトが出ています。
マルチパスQUICはマイルストーン上は2017年の後半に拡張の仕様が出て来る予定ですが、それに先立って考察のドラフトが出ている状況です。今後関連するドラフトも出てくるでしょう。
今回提出されているドラフトは、Huaweiの人らが書かれている「One Way Latency Considerations for Multipath in QUIC」というドラフトです。
"One Way Latency"は既にMultiPath TCPでも議論されている概念であり、そちらでもドラフト(URL)が出ています。
そもそも各通信路は、行きと帰りで同じレイテンシとは限りません。そのため複数経路を使用する場合は、RTTではなく片方向のレイテンシ(One Way Latency)を見て送信する経路を選択すべきということになります。RTTの値は輻輳制御やパケロスの検出に利用されますが、同様に複数経路の場合はOne Way Latencyを見るべきです。またレイテンシ同様、輻輳も片方向には輻輳しているが、反対側は輻輳していないというケースがあります。
たとえば、上記図の用に、クライアント・サーバ間で2経路あった場合。RTTだけみれば上の経路のほうが良いですが、クライアントからサーバに送信する場合は下の経路のほうが低レイテンシということもあるわけです。特に動画のキーフレームや重要なシグナル、ロスしたパケットの再送など急ぐものに関しては下の経路で送信したほうが良いということになります。
このドラフトでは、OWLの測定としてQUICのAckフレームに含まれるタイムスタンプを利用しますが、絶対値を得る方法と、相対値を得る方法について言及しています。
絶対値は各経路の各方向のOWLを計算します。各エンド間で時刻同期している前提になります。NTPといった別のプロトコルを利用して時刻同期を行えば、タイムスタンプを利用してOWLの絶対値が得られます。
相対値は、OWLの絶対値はわかりませんが、各経路の各方向でどの経路のOWLが小さいのかわかれば経路を選択できるようになります。これは時刻同期は必要なく、Ackフレームに含まれるタイムスタンプより計算されます。
2020/12/02追記 RFC 8879 とになったので、記事を書き直しました
asnokaze.hatenablog.com
GoogleとCloudflareの方による「Transport Layer Security (TLS) Certificate Compression」という、証明書チェーンの圧縮を行う拡張仕様の提案が出ています。
TLSハンドシェイクの大部分は証明書が占めているらしく、サーバ側から送る証明書チェーンをgzipかbrotliで圧縮できるようにする拡張仕様です。
証明書の圧縮についてはGoogle版QUICでは行っており、TLS1.3で圧縮をサポートするかという議論が昨年末にML上でありました( https://www.ietf.org/mail-archive/web/tls/current/msg22065.html )。
複雑性に見合う効果があるかは分からないが、TLS1.3だけに限る必要はないのではないかという意見が出ていたようです。
IETF版QUICにも証明書の圧縮機能が盛り込まれるかもしれませんが、この拡張を取り込む流れになるのかは分からないです。
QUICはUDPですので、サーバ側からの転送量を削減するのはAMP攻撃対策として大事なのではないかと思います。
クライアントは証明書の圧縮に対応している場合、ClientHello内でcompress_server_certificates拡張を使って対応してる圧縮アルゴリズムのリストをサーバに送信します。
enum {
zlib(0),
brotli(1),
(255)
} CertificateCompressionAlgorithm;
struct {
CertificateCompressionAlgorithm algorithms<1..2^8>;
} CertificateCompressionAlgorithms;
サーバはクライアントが提示したアルゴリズムに対応していた場合、ServerHelloで同じようにどのアルゴリズムを選択したかを返答します。
ServerHelloで使用するアルゴリズムを通知した場合、Certificateメッセージは以下のように圧縮前の長さと圧縮された証明から構成されます。
struct {
uint24 uncompressed_length;
opaque compressed_certificate_message<1..2^24-1>;
} Certificate;
server_certificate_type 拡張[RFC7250]の場合も、そのメッセージが圧縮されます。cached_info拡張[RFC7924] とは併用できません。
復号されたあとは、Certificateメッセージは圧縮がなかったようにそのまま処理されます。
まだ、WIPではあるもののCSPの仕様に "report-sample" と言う機能が追加されました(URL)。
これは、違反したインラインのScriptやStyleの最初の40文字がレポートに追加されます。外部ファイルの場合はレポートされません。昨年から議論がされていましたが、もともとはFirefoxに以前実装されていたscript-sampleプロパティと同等の機能ですが、Styleも対象になります。
これにより、今までレポートは送られてくるもの攻撃なのかそうじゃないのか分からなかったというケースが、多少なりとも少なくなるのではないだろうか。
普通のCSPと同様に、HTTPヘッダもしくはmetaタグで report-sampleを指定します。
Content-Security-Policy: script-src 'nonce-abc' 'report-sample'
<meta http-equiv="Content-Security-Policy" content="style-src 'nonce-abc' 'report-sample'">
下記のようなタグが含まれていた場合
<script>alert(1);</script>
このようにレポートにsampleが追加されます
{
...
"sample": "alert(1);"
}
