internet-draft

QUICにおける信頼性のないストリームの提案仕様

QUICはUDPを使用しますが、内部的にストリームという信頼性のある通信単位をもちます。ストリーム上では正しい順序での配送が保証され、パケットロスしたデータも回復されます。そのようなQUICに対して、信頼性のないストリーム、つまりパケットロスしても回…

TLS record_size_limit 拡張の提案

IoTデバイスなどリソースが制限されている端末でTLS通信を行うのには課題がある。特に送られてきたレコードを復号するのにはそれを計算する十分なメモリが必要になる。リソースが制限されている端末でも問題なく復号処理が出来るように、相手に受信したいレ…

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

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

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

20180313追記 QCRAMと呼ばれていた仕様は、QPACKに改称されました。 github.com 20180212 draft-04の変更点について その2を書きました。 asnokaze.hatenablog.com QUICとヘッダ圧縮 HTTP over QUICの仕様は現状、HTTP/2と同様HPACK(RFC 7541)を利用してHTTP…

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

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

Happy Eyeballs Version 2 の仕様 (RFC8305)

2017/12/22 RFC8305として標準化されました。 なお、下記内容は標準化中の内容につき一部古いかと思われます。 IPv4とIPv6両方が利用可能なデュアルスタック環境において、通信する際にIPv6とIPv4を並列的に試してより早く通信の確立が出来た方を試す Happy …

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

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

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

20180208追記 Bundled HTTP Exchangesについて記事を書きました Bundled HTTP Exchanges とは (WebPackagingの議論より) - ASnoKaze blog20180121追記 署名の仕組みとして Origin-Signed HTTP Exchanges を利用する方向のようです HTTP/2 クロスオリジン サ…

TLS1.3の0-RTT通信と、HTTP 425 ステータスコードの提案仕様

20170906 追記 無事Too Earlyのステータスコードが 425になりそうです。 https://github.com/httpwg/http-extensions/pull/39320171019 追記 https://tools.ietf.org/html/draft-ietf-httpbis-replay-01 draft-01にて425 (Too Early)となりました本記事は、d…

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つについて書かれ…