internet-draft

新しいユーザエージェント表現 User Agent Client Hints の提案仕様

ユーザエージェントは歴史的背景により、複雑な文字列が使用されています。iOSでは User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 12_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/69.0.3497.105 Mobile/15E148 Safari/605.1Edgeで…

HTTP over QUICと、その名称について (HTTP3について)

さてHTTP/3というと、なにか新しそうなHTTPのような気がしますが、まず基本的なHTTPのセマンティクスに変更はありません。GETやPOSTといったHTTPリクエストがあって、ステータスコードを持つレスポンスが返されます。ただその伝達方法がQUICトランスポートに…

QUICの話 (QUICプロトコルの簡単なまとめ)

20181106追記 HTTP over QUICについてちょっと書きました asnokaze.hatenablog.com QUICの話 QUICのプロトコルについて、自分の理解を整理するためにその中身について簡単にまとめていきたい。本当は体系的にちゃんとまとめていきたい。。。(なお、draft16を…

HTTP 418ステータスコードが予約される

「418 I’m a tea pot」としてよく知られる 418 ステータスコードについて、IETF HTTPbis WGで議論になっていました。「418 I’m a tea pot」はジョークRFCである「RFC2324 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)」で定義されているステータス…

NTPを暗号化する Network Time Security for NTP の提案仕様

サーバが正しい時刻に設定されていることは重要であり、時刻同期に使用されるNTPにおいてもサーバの認証や改ざんを防ぎたいというモチベーションは理解できる。IETFのNTP WGでは、まさにNTPを暗号的に保護する「Network Time Security for the Network Time …

QUICの信頼性のないデータグラム拡張(MESSAGEフレーム/Datagramフレーム)

QUICはUDP上で暗号化された信頼性のあるデータ通信を提供するトランスポートプロトコルです。現在IETFの「QUIC WG」で標準化が進んでおり、先行して実装されていたGoogle版QUICもIETF版QUICへの移行が進められています。 QUICのアプリケーションレイヤ 現在Q…

キャッシュがHitした情報を示すCacheヘッダの標準化提案

CDNなどのサービスは、リクエストがキャッシュにヒットしたかどうかをx-cacheヘッダに格納してレスポンスしてくれますこのx-cacheヘッダは独自の形式であり、例えば以下のようになっています。 (CDNによっては、x-cache以外のヘッダを使うものもあります)f…

DNS over HTTPSサーバを見つけるためのTXTレコードの提案仕様

DNS over HTTPS(DoH)の標準化が進められており、引き続き注目を集めている。 asnokaze.hatenablog.com一方で、DoHサーバをどのように見つけるか、見に行かせるかの議論が始まっています。 JPNIC Blog :: DNS over HTTPSとDHCP -IETF102における議論- で紹…

セキュリティトークンを識別するための secret-token URI Scheme の提案仕様

セキュリティートークンを間違えて公開してしまうセキュリティインシデントが増えています。例えば、シークレットやトークンをソースコードに埋め込んだままコミット・公開してしまったりなどです。機械的にセキュリティトークンを識別できるようになれば、…

Cookieにかわる Sec-HTTP-State ヘッダの提案

Cookieの様々な問題を解決するために、Webセキュリティー界隈で活躍されるMike West氏から「Tightening HTTP State Management」というCookieに変わるHTTPにおいてステートを扱う仕組みが提案されています。現在はIETFのHTTPbis WGのMLに投稿されただけで仕…

TLS1.0, TLS1.1 の廃止する提案仕様

TLS1.3にRFC8446が採番され、RFCとして出るのを待つばかりになっている。一方で、「Deprecating TLSv1.0 and TLSv1.1」というTLS1.0とTLS1.1の廃止についての提案仕様がIETFで出ている。 TLS1.0, TLS1.1 廃止事情 カード情報セキュリティの国際統一基準 PCI …

Forwarding-Loop Attacks攻撃を防ぐCDN-Loopヘッダの提案仕様

Forwarding-Loop Attacks攻撃を防ぐ「CDN Loop Prevention」 という仕様が提案されています。 背景 CDNへのDoS攻撃として、リクエストをCDN内でループさせる「Forwarding-Loop Attacks」という攻撃手法が知られています。CDNユーザの設定ミスや、攻撃者がユ…

QUICの現状確認をしたい 2018/5 (Stream 0の再設計案などなど)

IETFでは引き続き、QUICの標準化が進められています。前回から時間が空いてしまったが、メモ程度に今月も書いとく前回分 asnokaze.hatenablog.com 現状確認したい ちょうど先週に、コアドキュメントのdraft-12も出ています QUIC: A UDP-Based Multiplexed an…

GREASE for HTTP/2 の提案仕様

AkamaiのMike Bishop氏から、「GREASE for HTTP/2」という提案仕様が出ています。HTTP/2では、未知のフレームタイプとSETTINGSパラメータは無視するようになっています。これは、将来HTTP/2を拡張できるようにするためで、実際に「RFC 8336 The ORIGIN HTTP/2…

プロトコルにおける「堅牢性原則」は害悪か

Internet Architecture Board (IAB)でもあるMartin Thomson氏から「The Harmful Consequences of the Robustness Principle」という文書が提出されている。これは、堅牢性原則(Robustness Principle)について言及している文書である Robustness Principle プ…

TLSにおけるTicketRequest拡張の提案仕様

Appleの人らによって「TLS Ticket Requests」という、TLSでのセッション再開に利用するチケットに関する拡張仕様が提案されています。TLSはあまり詳しくないのですが簡単に読む TLS session ticket まず、TLS session ticketとセッション再開について確認する…

HTTP Server Pushのセマンティクス拡張する、HTTP Server *ush の提案仕様

4/1 に「HTTP Server *ush」という提案仕様が、IETFに提出されています。4/1にです。 HTTP Server *ush 「HTTP Server Push」の音節構造は非常に舌に馴染むものです。HTTP Server Pushの成功の一つの理由でしょう。そこで、同じ音節構造を持つ様々な「HTTP S…

QUICの現状確認をしたい 2018/3 (QPACK, Spin Bit, Invariants)

QUICの現状確認をしたい。 (あまり追えてないのでつらい)前回 asnokaze.hatenablog.com次回 asnokaze.hatenablog.com 目次 仕様の状況 マイルストーンの変更 IETF101 相互接続性テスト Spin Bit QUIC DTLS and Stream 0 A First Look at QUIC in the Wild …

ChromeがWebSockets over HTTP/2に対応したので試す (RFC8441)

2018/09/19追記 RFC 8441 として標準化されました 以前書いたとおり、Websockets over HTTP/2の仕様である「Bootstrapping WebSockets with HTTP/2」が現在標準化が進められている。 asnokaze.hatenablog.comこれにより、複数のWebsocket通信が1つのTCPコネ…

QUIC over DTLSの提案仕様

20180601追記 asnokaze.hatenablog.com 「QUIC over DTLS」という提案仕様ekr氏が出され、QUIC WGのメーリングリストで「Proposal: Run QUIC over DTLS」としてDTLS上でQUICのメッセージを通信するように変更する提案がされている。 QUICのスタック 現在のQU…

HTTP/1.1 (RFC 7230 〜 7235) の改訂作業がはじまる

20181020追記 「HTTP 418ステータスコードが予約される」で触れたように、改定仕様は現在3つの仕様に整理されて作業が進められています。 HTTP/1.1の仕様は下記の通り、6つのRFCで標準化されています。 RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): …

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

20180615追記 Bundled HTTP Exchangesの仕様がIETFに提出されました https://tools.ietf.org/html/draft-yasskin-wpack-bundled-exchanges-00 WebPackagingという仕様が議論されている。簡単な概要は以下の記事に書いたとおり asnokaze.hatenablog.comWICG/w…

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

3月分も書きました asnokaze.hatenablog.com QUICの標準化状況に関して、幾つかトピックを取り上げるシリーズ化するつもりは無いが、1月に書いたので、今回は2月初旬版 qiita.com拾いきれてないトピック沢山有るので、皆さんも是非補足して頂ければ目次 Draf…

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 クロスオリジン サーバプッシュを可能にする提案仕様

ちょっと不明瞭な部分が修正できてません。すみません。20180824追記 Loading Signed Exchangesについて記事を書きました Loading Signed Exchangesの仕様 (WebPackaging) - ASnoKaze blog20180213補足 「Origin-signed HTTP Responses」は「Signed HTTP Exc…

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

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

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 …