Home » Posts tagged "ietf"

TLS 1.3 進入 Proposed Standard

最近蠻熱的一個新聞,TLS 1.3 的 draft-ietf-tls-tls13-28.txt 進入 Proposed Standard 了 (在「draft-ietf-tls-tls13-28 - The Transport Layer Security (TLS) Protocol Version 1.3」這邊可以看到歷史記錄):「Protocol Action: 'The Transport Layer Security (TLS) Protocol Version 1.3' to Proposed Standard (draft-ietf-tls-tls13-28.txt)」。

沒意外的話這就會是最終版本了。如果要看 TLS 1.2 與 TLS 1.3 的差異,看維基百科上的 Transport Layer Security - TLS 1.3 會比較清楚。

大家等很久了... 像是 OpenSSL 1.1.1 其實一部分也是在等 TLS 1.3 正式推出:(出自「Using TLS1.3 With OpenSSL」)

OpenSSL 1.1.1 will not be released until (at least) TLSv1.3 is finalised. In the meantime the OpenSSL git master branch contains our development TLSv1.3 code which can be used for testing purposes (i.e. it is not for production use).

主要還是期待非 NSA 派系的 cipher (其實幾乎都是 djb 的戰果) 與 1-RTT handshake,後續等 TLS 1.3 變成 Standard Track 應該就會被各家瀏覽器開預設值了...

End-to-End Encryption 的標準?

看到「The Messaging Layer Security (MLS) Protocol」這個被提出來的標準,還在討論中...

簡介就說明了這個標準除了標準的 E2E 外,還設計了有效率的 Group 機制:

Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two participants need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands.

要設計機制的人可以拿來翻翻看...

新出的 RFC 8259:The JavaScript Object Notation (JSON) Data Interchange Format

JSON 的規格書又被更新了 XD

在「The Last JSON Spec」這邊,Tim Bray 寫了這篇關於新的 RFC 8259 跟之前的差異,以及大家對於雙重標準的顧慮。

最大的差異在於,在 RFC 8259 規定了「如果 JSON 被用在非封閉的系統交換資料,必須使用 UTF-8」:

8259 con­tains one new sen­tence: “JSON text ex­changed be­tween sys­tems that are not part of a closed ecosys­tem MUST be en­cod­ed us­ing UTF-8 [RFC3629].” Giv­en that, by 2017, an at­tempt to ex­change JSON en­cod­ed in any­thing but UTF-8 would be ir­ra­tional, this hard­ly needs say­ing; but its ab­sence felt like an omis­sion.

而關於 ECMA-404 與 RFC 8259 都定義了 JSON 的問題他也說明了,因為很多人花了很多力氣在確保這兩份文件的正確性上,所以應該不會有問題 (i.e. 衝突):

The rea­son 8259 ex­ists is that the ECMAScript gang went and wrote their own ex­treme­ly min­i­mal spec, Stan­dard ECMA-404: The JSON Da­ta In­ter­change Syn­tax, and there was rea­son for con­cern over du­el­ing stan­dard­s. But, af­ter a cer­tain amount of standards-org elephant-gavotte, each of ECMA 404 and RFC 8259 nor­ma­tive­ly ref­er­ences the oth­er and con­tains a com­mit­ment to keep them con­sis­tent in case any er­rors turn up. Which is a good thing, but this text has been re-examined and re-polished so many times that I doubt ei­ther side will ev­er re­vis­it the ter­ri­to­ry, thank good­ness.

另外他也提到了對於不同情境下可以看不同的文件。像是要了解 JSON 的話,可以看當初發明 JSON 的 Doug Crockford 所設立的網站 (在「JSON」這邊);而在交換時應該參考 I-JSON (Internet JSON,RFC 7493):

Which spec should you use? · If you want to un­der­stand JSON syn­tax, you still can’t beat Doug Crockford’s orig­i­nal for­mu­la­tion at JSON.org. If you want to use an RFC as foun­da­tion for a REST API or some oth­er In­ter­net pro­to­col, I ac­tu­al­ly don’t rec­om­mend 8259, I rec­om­mend I-JSON, RFC 7493, which de­scribes ex­act­ly the same syn­tax as all the oth­er specs (by ref­er­enc­ing 7159), but ex­plic­it­ly rules out some legal-but-dumbass things you could do that might break your pro­to­col, for ex­am­ple us­ing any­thing but UTF-8 or hav­ing du­pli­cate mem­ber names in your ob­ject­s.

I-JSON 是 JSON 的子集合,比較重要的:

  • (MUST) 使用 UTF-8。
  • (SHOULD NOT) 浮點數的部份,不得超過 IEEE 754-2008 binary64 (double precision) 的範圍。
  • (SHOULD NOT) 整數的部份,不得超過 [-(2**53)+1, (2**53)-1]) 的範圍。
  • (RECOMMEND) 有超過的需求使用字串表示。
  • (MUST NOT) JSON object 內不得有重複的 name。
  • (SHOULD NOT) 最上層的型態不得使用字串,只能使用 object 或是 array。
  • (MUST NOT) 遇到先前沒有定義過的元素不得視為錯誤。(像是新版 API 內會在 object 裡增加元素)
  • (RECOMMEND) 時間使用 ISO 8601 表示 (在 RFC 3339 有提到),英文字的部份全部使用大寫,一定要標上時區,而秒數的 0 一定要加上去 (也就是 00 秒)。
  • (RECOMMEND) 時間長度也建議依照 RFC 3339 處理。
  • (RECOMMEND) Binary 資料用 base64url 傳 (RFC 4648)。

QUIC 的進展

在「New Work in Seoul」這邊看到 QUIC 的消息:

The QUIC working group has just been chartered, and will meet for the first time in Seoul. This working group is taking Google’s pre-standardization QUIC protocol that has been deployed in production for several years, and will use it as a starting point to develop a UDP-based, stream-multiplexing, encrypted transport protocol with standardized congestion control, TLS 1.3 by default, a mapping for HTTP/2 semantics over QUIC, and multipath extensions. This is the IETF’s first standardized always-encrypted transport protocol, so careful consideration of applicability and operational capabilities will be key for success.

IETFDatatracker 上也可以看到記錄了:「QUIC (quic)」,最下面的 Milestones 可以看到第一階段的目標是在明年二月把基本的協定都定下來,之後再加東西上去。

CloudFlare 全面支援 DNSSEC

CloudFlare 宣佈全面支援 DNSSEC 了:「Announcing Universal DNSSEC: Secure DNS for Every Domain」。

另外也因為現在需要把 public key 手動 copy & paste 到 DNS 註冊商會很麻煩 (而且有可能會貼錯),所以 CloudFlare 的人試著往 IETF 標準化這件事情:

At CloudFlare, we care about advancing what’s possible on the Internet, so we have published an Internet Draft proposing a protocol for DNS providers such as CloudFlare to communicate directly to registries and registrars. We are pushing it to become an accepted Internet Standard RFC.

RFC7686:保留 .onion 給 Tor 的 Hidden Services 使用

看到 Tor Project 很高興的宣佈 .onion 這個 TLD 在 RFC 7686 成為 Standards Track:「Landmark for Hidden Services: .onion names reserved by the IETF」。

而且也因為成為 IETF 的標準,在 CA/Browser Forum 上更有依據討論在上面的 CA 架構:

With this registration, it is should also be possible to buy Extended Validation (EV) SSL/TLS certificates for .onion services thanks to a recent decision by the Certification Authority Browser Forum.

Google 推出 Brotli 無損壓縮法

Google 推出了 Brotli 這個無損壓縮法:「Introducing Brotli: a new compression algorithm for the internet」。

Google 推出的 Zopfli 相容於 DEFLATE 的超慢壓縮演算法,但可以多壓榨出 3%~8% 的壓縮率。而 Brotli 則是重新設計,壓縮與解壓縮速度跟 DEFLATE 差不多,但壓縮率比 Zopfli 多了 20%~26%。

This new format allows us to get 20–26% higher compression ratios over Zopfli. In our study ‘Comparison of Brotli, Deflate, Zopfli, LZMA, LZHAM and Bzip2 Compression Algorithms’ we show that Brotli is roughly as fast as zlib’s Deflate implementation.

由於目標是希望讓瀏覽器支援新的壓縮法,Google 把 Brotli 往 RFC 提案,試著變成公開標準:「Brotli Compressed Data Format」。

看了看 commit log,看起來已經開發一陣子了...

.onion 的域名保護

.onion 被用在 Torhidden service,而現在從不同的面向要保護這個 root domain 不被註冊,在 IETF 的 blog 上看到「.onion」這篇文章就是其中一個方向。

這邊的計畫是把 .onion 域名當作像是 .local.localhost.example 這樣的特殊域名保護 (參考 RFC 6761「Special-Use Domain Names」) 而提了一個新的 RFC (目前是 draft):「The .onion Special-Use Domain Name」。

如果通過的話,就有一個標準可以遵循,不然現在對 .onion 一直都是 De-facto standard...

用 Require-Recipient-Valid-Since (RRVS) 解決帳號失效的問題

在「Facebook Yahoo Require-Recipient-Valid-Since SMTP Extension」這篇看到 Require-Recipient-Valid-Since (RRVS) 變成 Proposed Standard 了:「The Require-Recipient-Valid-Since Header Field and SMTP Service Extension」(RFC 7293)。

起因是從 2013 年的「yourname@yahoo.com Can Be Yours!」這篇開始的:Yahoo! 宣佈會釋出太久沒有使用的 @yahoo.com 帳號讓其他人可以註冊。

而這導致了帳號綁定問題:如果使用者先前在 Facebook 上 (或是其他服務) 有綁定 Yahoo! 帳號,而他的 Yahoo! 帳號被釋出被其他人拿走後,其他人就可以利用重設密碼的功能取得 Facebook 帳號權限。

Yahoo! 對這個問題的解法是透過 Require-Recipient-Valid-Since 處理,服務方 (像是 Facebook) 在發出重要信件時帶入 Require-Recipient-Valid-Since,要求這封信必須在某個時間點後有效,才能讓收信者看到這封信的內容。

Facebook 的人在「Protecting Facebook Accounts With New Email Standard」也提到了這個新標準。

Archives