internet-draft

Bundled HTTP Exchanges とは (WebPackagingの議論より)

WebPackagingという仕様が議論されている。簡単な概要は以下の記事に書いたとおり asnokaze.hatenablog.comWICG/webpackageで書かれている通り、WebPackagingは以下の2つに分離して標準化が進められそうです Signed HTTP exchanges: HTTPリクエスト/レスポン…

QUICの現状確認をしたい 2018/2 (MTU, Migration, Packet Number Encryptionなど)

QUICの標準化状況に関して、幾つかトピックを取り上げるシリーズ化するつもりは無いが、1月に書いたので、今回は2月初旬版 qiita.com拾いきれてないトピック沢山有るので、皆さんも是非補足して頂ければ目次 Draft-09 Call for Adoption 接続性テスト(Intero…

Application-Layer TLS の標準化動向

IETFでApplication-Layer TLSの議論が行われ始めているので、雑に書き留めておく Application Transport LAyer Security (Atlas) 前回、アプリケーションレイヤでTLSを喋る「HTTP over TLS」について、記事を書いた。 asnokaze.hatenablog.com その後、IETF…

DNSで負荷分散を可能にするLBレコードの提案

名前解決を行っているクライアントの国や地域によって、近い場所のサーバのIPを返すといったことは既に行われている。しかし、そのDNSによる負荷分散の方法は標準化されていない。「DNS load balancing」という提案仕様では、新しくLBレコードを定義し、権威…

DNS ALTSVC recordの提案仕様

Alternative ServicesをDNSで通知できるように、ALTSVCレコードを定義する「Finding HTTP Alternative Services via the Domain Name Service」という仕様が出ています。DNSレコードタイプの議論ですが、HTTPbis WGから議論が始まっています。 HTTP Alternat…

HTTP/2 クロスオリジン サーバプッシュを可能にする提案仕様

ちょっと不明瞭な部分が修正できてません。すみません。20180213補足 「Origin-signed HTTP Responses」は「Signed HTTP Exchanges」に改称されました。この仕様では、HTTP Exchange(リクエストとレスポンス)両方を署名対象にし、それらの署名値であるSignat…

そろそろ標準化されるHTTP/2 ORIGIN フレームについて

HTTP/2の拡張仕様で、ORIGINフレームという提案仕様が大詰めを迎えています。 https://tools.ietf.org/html/draft-ietf-httpbis-origin-frame-05 IESGに送られていますが、現在のところでは反対意見は出ていません。このORIGINフレームについては、数年前に…

Amazonの人が提案するDistributed OAuthという提案仕様

AnazonのDick Hardt氏が「Distributed OAuth」という仕様を提案している。昨年行われたIETF100でも議論があり、来週行われるOAuth WG Virtual Meetingでも話が進められるようだ。遅らせばながら簡単に読んで見る。 Distributed OAuthとは 通常のOAuth2では、…

RFC 8307 WebSocketにおけるWell-Known URIの標準化

「RFC 8307 Well-Known URIs for the WebSocket Protocol」でWebSocketにおいても Well-Known URIが使用できるようになりました。この界隈では珍しく、個人ドラフトの-00から一気にRFCになっています https://datatracker.ietf.org/doc/rfc8307/ Well-Known …

DTLSにコネクションIDを導入する提案仕様

DTLSにコネクションIDを導入する「The Datagram Transport Layer Security (DTLS) Connection Identifier」という提案が出ています。DTLS1.3の議論を進める中で出てきたトピックであり、既にWG Draft になっています。 DTLSとセッション DTLSはUDPのようなコ…

将来のQUICをデプロイしやすくするための取り組みと議論 (QUIC GREASE)

MozillaのM. Thomson氏より「More Apparent Randomization for QUIC」というinternet draftが出ています。 ## QUICのここまで QUICはIETFで標準化が進められています。当初は2018年3月が一つのマイルストーンになっていましたが、スコープとマイルストーンの…

ライブコンテンツにおけるHTTP Rangeリクエストを改善する提案仕様

ライブコンテンツやログデータといった常に大きくなり続けるコンテンツに対するRangeリクエストを改善する提案仕様がIETFのHTTPbisで出ています。その仕様は「HTTP Random Access and Live Content」であり、すでにWGアイテムとなっておりWorking Group Last…

QUIC Invariantsの議論

QUICは現在IETFで標準化が進めれています。QUIC WG出来、本格的に標準化が開始して1年ほど立ったところで、スケジュールとスコープの議論(QUIC - Our schedule and scope)が出てきており、QUIC Version1としてどの機能を標準化する話が行われてる一方で、Inv…

QUICのSpin Bitの議論

QUICはUDP上でTCP+TLS+HTTP/2の機能を持つ新しいプロトコルであり、IETFで絶賛標準化中です。7月にあったIETF99より、Spin Bitというトピックが議論されているので簡単に書く。以前、下記記事にも書いたとおりQUICではACKなどを含む殆どの制御情報も暗号化さ…

TLS over HTTPの提案仕様

追記 関連してATLSの記事を書きましApplication-Layer TLS の標準化動向 http://asnokaze.hatenablog.com/entry/2018/02/01/084251 TLS over HTTPである。HTTP over TLSではない。「Application-Layer TLS」という提案仕様がCiscoの方より提出されている。(…

HTTPヘッダに構造定義を与える Structured Headers の提案仕様

HTTPヘッダには、リストや辞書といった構造を表現するのに決まったやり方はありません。HTTPヘッダ毎にシンタックスや構造が定義されており、そのためパーサーが再利用出来ません。mnot氏とphk氏の共著で提出された「Structured Headers for HTTP」仕様では…

QUICとネットワーク管理/オペレーションの話

あわせて下記記事も参照のこと asnokaze.hatenablog.com ワイヤイメージ 経路上で出来ること QUICトラフィックの識別 バージョンの識別 不正なパケットの拒否 コネクション確立の確認 通信フローの関連付け 通信フローの切断検出(不可) ラウンドトリップタイ…

WebSockets over HTTP2 の提案仕様。再び。

2018/2/06追記 「Bootstrapping WebSockets with HTTP/2」はWG Draftになり、この方向で標準化が進む方向です。ただし、下記のプロトコルフローとは異なりHEADERSフレームでWebSocketのアップグレードを処理する手順になっています。Chromiumにおいても「Add…

TLS1.3とDC内での復号に関する熱い議論

各ブラウザや、OpenSSL・BoringSSLといった暗号ライブラリ、ミドルウェアのTLS1.3対応が進んでおり、実際に通信できるところまで来ている。標準化としても大詰めを迎えている。前回のIETFより話題に上がっている、TLS1.3に関するDC内での復号を目的とした議…

パスワードマネージャが適切にパスワードを生成できるようにするポリシーの提案仕様

パスワードの管理に、1PasswordやLastPassといったパスワードマネージャを使うのは一般的になってきています。そのようなパスワードマネージャはランダムなパスワードを生成しますが、Webサービスによって使える文字の種類や、長さというのはマチマチです。…

キャッシュサーバの効率を改善するHTTP Variantsという提案仕様

HTTP Variants IETFのHTTP WGやQUIC WGのチェアをしているmnot氏より、キャッシュの効率が改善する「Variants」というHTTPレスポンスヘッダを定義する「HTTP Variants」という提案仕様が出ています。この機能は、Fastly VCLの機能の標準化のようです。少々想…

DNS Queries over HTTPS の標準化

「DNS Queries over HTTPS」の仕様の標準化が始まっている。今までもこのテーマはIETFにおいて何度か議論になってきましたが、今回 DNS Over HTTPS (doh) WGの設立に合わせて(まだProposed)、この「DNS Queries over HTTPS」の標準化がマイルストーンとなっ…

セキュリティの報告先を記述する、security.txtの提案仕様

Webサイトのセキュリティリスクを発見したものの、連絡先が適切に公開されていないがために、結局報告されず脆弱性が放置されるケースがあるようだ(国内だと、IPA脆弱性関連情報の届出受付もあるが)発見者が脆弱性等の報告を出来るような情報を、Web作成者が…

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におけるヘッダ圧縮の提案仕様 QCRAM

20180212 draft-04の変更点について その2を書きました。 asnokaze.hatenablog.com 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 の仕様 (RFC8305)

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

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

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