internet-draft

ジオロケーションを要求・送信する HTTP Geolocationヘッダの提案仕様

GoogleのLuis Barguno Jane氏より、HTTPヘッダでジオロケーション情報の要求・送信を可能にする「Geolocation Header for HTTP over a Secure Context」という仕様が出ています。 背景 ユーザエージェントにおいてジオロケーションの取得は「Geolocation API…

QUICにおけるヘッダ圧縮の提案仕様 QCRAM

QUICとヘッダ圧縮 HTTP over QUICの仕様は現状、HTTP/2と同様HPACK(RFC 7541)を利用してHTTPヘッダの圧縮を行う。HPACKはHTTP/2を想定としており、トランスポートはTCPであり順番通りにパケットが届く想定の仕様となっている。具体的には、動的テーブルにお…

HTTP/2でのプライオリティ・プレースホルダの提案仕様

元々はHTTP over QUICでの議論に端を発するが、HTTP over QUICの仕様の著者でもあるMicrosoftのMike Bishop氏から「Priority Placeholders in HTTP/2」という仕様が提案されている。解説すると長くなるので割りと雑目ですみません HTTP2のプライオリティ制御…

Happy Eyeballs Version 2 の仕様

IPv4とIPv6両方が利用可能なデュアルスタック環境において、通信する際にIPv6とIPv4を並列的に試してより早く通信の確立が出来た方を試す Happy Eyeballs という仕組みがあります。より環境の良い方を使うだけでなく、IPv6で通信を試みてからうまくいかない…

.internal ドメインを予約する提案仕様

IETFのdnsop WGで .internal ドメインを予約する「The .internal TLD.」という仕様が、GoogleのWarren Kumari氏によって提案されています。DNSに関しては詳しくないのですが、ざっと読んだので簡単にメモ。 .internal .internalというドメインを内部的に使用…

Webページを丸ごとパッケージングする Web Packagingとは

Webページを丸ごとパッケージングする、Web Packagingの仕様がIETFで提案されていますオフラインやローカル環境で共有出来るようになっており、主な特徴は 証明書及び署名がつけられるため、そのパッケージの真正性が確認できる HTTPリクエスト/HTTPレスポン…

TLS1.3の0-RTT通信と、HTTP 4NN(未定) ステータスコードの提案仕様

TLS1.3では、0-RTTハンドシェイクの際にearly_dataとしてアプリケーションデータを送信できます。しかし、この0-RTTハンドシェイクで送信するデータには、リプレイ攻撃のリスクがあります。 そのリスクをさけるための機能をHTTPに追加する提案が出ています。…

DNS ANAMEレコードの提案仕様

IETFでのDNS関連の標準化は普段追ってないので恐縮だが、DNSOP(DNS OPerations)WGで気になったドラフトがあったので読んで見る。「Address-specific DNS Name Redirection (ANAME)」という提案仕様であり、先日WGドラフトになったようだ。著者は、ISC, Power…

RFC8174「RFC 2119のキーワードにおける大文字と小文字の曖昧性」

RFCやInternet-Draftを読んだことある人であれば、文中にMUSTやSHOULDといった大文字のキーワードが用いられてるのを見たことあるかと思います。たとえば、このように An endpoint MUST treat this as a stream error (Section 5.4.2) of type PROTOCOL_ERRO…

hxxp URIスキームの仕様化

追記 20170510 draft-01 より、hxxpsも予約されました 「The "hxxp" and "hxxps" URI Schemes」 hxxpの背景 hxxp URIを定義する「The "hxxp" URI Scheme」という仕様が提案されています。hxxp://... は、例えばセキュリティの話をする際にURLがリンクとして…

Cookieの仕様改定版、RFC6265bisの議論

Cookieの仕様と拡張仕様 HTTPのCookieの仕様は RFC 6265 - HTTP State Management Mechanism で定義されております。2015年頃より、IETFのHTTPbisワーキンググループではCookieのセキュリティを向上させる目的で拡張仕様が3つほど議論されていました。 Cooki…

WebサーバとのコネクションでDNS通信もする拡張仕様

追記 20170510 この提案仕様は、draft01でauthor自ら廃案とされました。 昨日の「DNS over QUICの提案仕様が出た」引き続きDNS関連の記事 DNSとHTTP 近年注目されている、"DNS over HTTP"は例えば「DNS-over-HTTPS」としてGoogleが提供していたり、IETF97で…

DNS over QUICの提案仕様が出た

QUICの標準化とアプリケーションレイヤ IETFでQUICの標準化が活発に行われており、トランスポート・TLS・HTTP各レイヤのドラフト仕様の改定が進められております。 標準化を行うにあたって当初より、DNSのトランスポートとしてQUICを使用したいという話題は…

マルチパスQUICにおけるOne Way Latencyの考察

QUICの各仕様のdraft-02が出た一方で、マルチパスQUICに関する考察ドラフトが出ています。 マルチパスQUICはマイルストーン上は2017年の後半に拡張の仕様が出て来る予定ですが、それに先立って考察のドラフトが出ている状況です。今後関連するドラフトも出て…

TLSにおける証明書チェーンを圧縮する拡張仕様

GoogleとCloudflareの方による「Transport Layer Security (TLS) Certificate Compression」という、証明書チェーンの圧縮を行う拡張仕様の提案が出ています。 TLSハンドシェイクの大部分は証明書が占めているらしく、サーバ側から送る証明書チェーンをgzip…

HTTP over マルチキャストQUIC とは

「Hypertext Transfer Protocol (HTTP) over multicast QUIC」で、マルチキャストのQUIC上でHTTP通信を行う仕様が提案されている。マルチキャストQUICは単方向通信であり、その上でサーバプッシュを行う感じである。 現状QUICの仕様ではIPマルチキャストの利…

Content-Encoding: aes128gcm とは (RFC8188)

20170624追記 RFC8188 として標準化されました HTTPリクエスト・レスポンスのボディを暗号化する、「Content-Encoding: aes128gcm」を新しく標準化する「Encrypted Content-Encoding for HTTP」という仕様が議論されております。 提案自体は数年前に行われて…

CT対応を示すExpect-CTヘッダとは

正式に、Expect-CTのDraftが出ました (10/31 追記)https://tools.ietf.org/html/draft-stark-expect-ct-00 Certificate Transparency Certificate Transparencyと呼ばれる、不正な証明書の発行を検知する仕組みがGoogle社によって考案され、RFC 6962として標…

CloudFlareの提案するHTTP/2の圧縮辞書拡張

IETFのHTTPbis wgでCloudFlareの方より「Compression Dictionaries for HTTP/2」(URL)という仕様が提案されている。 これは、Content-Encodingヘッダで指定される圧縮アルゴリズム向けの初期ウィンドウに使用される辞書データを事前に送る拡張を定義する。 C…

Secure Contextsに関する localhost と、IETFでの新提案

Secure Contexts Service Workers、Web BluetoothといったAPIは、安全に使用するためにセキュリティ上の条件があります。 その条件がSecure Contextと呼ばれるコンテキストであり、W3CのSecure Contexts(URL)というドキュメントで定義されています。 このSec…

Site-Wide HTTP Headers とは

Mark Nottingham氏から、HTTPレスポンスヘッダをサイト全体で使いまわせるようにする 「Site-Wide HTTP Headers」 という仕様が提案されています。https://tools.ietf.org/html/draft-nottingham-site-wide-headers-00 例えば、Public-Key-PinsやStrict-Tran…

QUICの仕様を翻訳していく

2017年追記 2017年時点で、仕様は更新され、拡張仕様も出てきています。 asnokaze.hatenablog.com QUIC in ietf96 「Google の試験的トランスポート、QUIC のアップデート」などでも紹介されている、Googleが提案・実装してるQUIC。 すでに関連するドキュメ…

安全でない通信路でセットされたCookieの有効期限を短くする仕様

安全でない通信路で設定されたCookieについて有効期限を短くする「Expiring Aggressively Those HTTP Cookies」という仕様がMozillaのMartin Thomsonから提案されています。 Expiring Aggressively Those HTTP Cookies https://tools.ietf.org/html/draft-th…

HTTP/2における証明書に基づいたリアクティブなクライアント認証 その2

この記事は Secondary Certificate Authentication in HTTP/2 という仕様にマージされました 「HTTP/2における証明書に基づいたリアクティブなクライアント認証 その1」(2015-10-23) 「Reactive Certificate-Based Client Authentication in HTTP/2」 の dr…

Captive Portal Problem Statementについて

Captive Portalについて議論を行うcapport wgが出来、IETF95で初めてのミーティングが行なわれます。 Captive Portalとは、よくWi-Fi接続後にブラウザでWebベースの認証が別途要求されるアレです。このCaptive Portalが引き起こす問題について議論をするため…

Limited Use of Remote Keys(Lurk)についてのメモ

kazuhoさんのIETF95参加報告資料が参考になるかと思います(20160608追記) http://www.slideshare.net/kazuho/tls-lurk-ietf-95 2016年1月に、IETFで"Limited Use of Remote Keys(Lurk)"と言う議論が始まりました。 Lurkに関する議論はIETF95のBoFで議論され…

HTTP/2 GZIPPED_DATA フレームとは

このエントリは、 http2 advent calendar の 8 日目の穴埋めです。 HTTP/2にGZIPPED_DATAフレームという拡張フレームを追加する提案が提出されている。フレームの追加に伴って、エラーコード・Settingsも追加される。 HTTP/2 Gzipped Data https://tools.iet…

HTTPのためのTCPチューニング (Best Current Practice)

HTTPを効率よく使用するためにTCPのチューニングはかかせません。 Best Current Practiceカテゴリとして「TCP Tuning for HTTP (draft 00)」というInternet-Draftが提出されているので、ざっと目を通した。(割と適当) 大きく分けて下記の5つについて書かれ…

HTTP/2に「ORIGINフレーム」を追加する拡張仕様

HTTP/2では、一定の条件が満たされれば異なるオリジンとの通信を一つのコネクション上で行うことが出来ます。サーバは、クライアントが要求したオリジンに対する権威がない場合は421 (Misdirected Request)を返します。 (条件等は、rfc7540#section-9.1参照…

サーバプッシュのための「Accept-Push-Policyヘッダ」とは

HTTP/2ではサーバプッシュと呼ばれる機能があります。サーバはクライアントからのリクエストを受信しなくても先んじてレスポンスを返すことができる仕組みになります。 たとえば、HTTP/1.1においてリソースをインライン化していた部分をサーバプッシュとして…

HTTP/2における証明書に基づいたリアクティブなクライアント認証 その1

draft 01で大きくな変更が加えられました。証明書を要求するフローは以下より大きく変わりました。ご注意ください (2016/01/27) 「HTTP/2における証明書に基づいたリアクティブなクライアント認証 その2」でdraft02について書きました(2016/05/04) HTTP/2に…

Cookieの属性を制限する Cookie Prefixesという仕様

"$Origin-"プレフィックスは削除され、"$Host-"プレフィックスが追加されました。 (2015/10/13追記)(2015/10/17 記事更新) 背景の、domain属性の指定に誤りがあったため修正しました。「domain=my-example.com」-> 「domain=example.com」(2015/10/14追記) d…

非セキュアなオリジンから'secure'クッキーの変更を廃止する提案

先日、HTTPSでsecure属性を付加した場合でも改変できると話が話題になりました。 クッキーの脆弱性が判明: HTTPS のセキュリティを突破する、攻撃が成り立ってしまう! HTTPSを使ってもCookieの改変は防げないことを実験で試してみた(2013/9/30) Cookies La…

Multipath TCPとL4バランシングのI-D

一年ほど前に書いた「MPTCP(MultiPath TCP)と負荷分散ってどうなんだろう」関連の話。 先日、まさに「Multipath TCP behind Layer-4 loadbalancers」と言うI-Dが出てました。iOSのsiriではMPTCPを使っているようですが、Appleの方もAuthorに含まれています。…

QUICの仕様(ドラフト)が公開されたので、概要を読む

QUICの仕様を翻訳していく http://d.hatena.ne.jp/ASnoKaze/20160725/1469374715 新しい仕様の翻訳を公開しました(2016/07/25) https://github.com/flano-yuki/my-quic-spec-translation QUIC: A UDP-Based Multiplexed and Secure Transport HTTP/2 Semanti…

TLS Jump Startとは

TLS Jump Start CloudFlareの方によって、TLS Jump Startという仕様が提案されている。 雑にですが簡単に斜め読みした(例のごとく間違い等あるかと思います) https://tools.ietf.org/html/draft-vkrasnov-tls-jumpstart-00 TLSの通信では初期接続時に複数…

HTTP Client-Initiated Content-Encoding

Client-Initiated Content-Encoding HTTP Client-Initiated Content-Encoding https://tools.ietf.org/html/draft-ietf-httpbis-cice-00 という、HTTPに関する拡張仕様が提案されており、4月にhttpbisのWGドラフトになっている。 Accept-Encodingヘッダをレ…

Origin Cookiesとは

Origin Cookies GoogleのMike West氏による、Cookieに対する拡張が提案されている。 draft-west-origin-cookies-01では、同一生成元ポリシーと同様なセキュリティポリシーでCookieを扱えるように、Cookie(RFC6265)に"Origin"属性を追加し、HTTPヘッダに"Orig…

ALPN HTTP Headerとは

TLS ALPNに関してはこちら TLS上でのプロトコルネゴシエーションの仕組み、NPNとALPN ALPN HTTP Header 現在、httpbis WGで提案されている「The Tunnel-Protocol HTTP Header Field」と言う仕様が、「The ALPN HTTP Header Field」に改称される見込みである…

Cache-Controlヘッダのstale-while-revalidateとは

20170215追記「Nginxがstale-while-revalidateに対応した」 http://d.hatena.ne.jp/ASnoKaze/20170211/1486820792 Chromeの「chrome://flags/」に「stale-while-revalidate キャッシュ指令を有効にする」と言うフラグがあったので、簡単に調べた。 「RFC5861…

MPEG‐DASHにおけるHTTP/2の使用、DASH-PUSHの提案

MPEG-DASHとHTTP/2 MPEG-DASH(Dynamic Adaptive Streaming over HTTP)と呼ばれるHTTP上で環境に合わせてビットレートを変更しながらストリーミングできる仕組みがある。このMPEG-DASHにHTTP/2を使うという話がいくつか出てきている。 たとえば、BBCの「Adapt…

CookieのFirst-Party-Only属性

draft 05より、「Same-site Cookies」という仕様に改称され、SameSite属性として属性が定義されました。 http://tools.ietf.org/html/draft-west-first-party-cookies-05 (2016/01/28) Googleの方による、CookieにFirst-Party-Only 属性を追加するという仕様…

SSLv3の使用が禁止される話

TLS WGでは「Deprecating Secure Sockets Layer Version 3.0(draft-ietf-tls-sslv3-diediedie-00 )」というI-DがWG Last Callになっています。 これは、SSLv3の使用を禁止するI-Dになります。 ざっと以下の様な事が書かれています。禁止されるという事実より…