RFC 裡面的 MUST/SHOULD/MAY

讀 RFC 文件時常看到會使用這組定義,甚至有些非 RFC 文件也會使用:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

這邊提到的 RFC 2119 就是 1997 年訂的「Key words for use in RFCs to Indicate Requirement Levels」這篇,以 2020 年的現在來說,這組定義已經被人熟知,用這組定義可以讓閱讀的人很輕鬆的了解條件的強制性。

剛剛在讀新的文件時發現這段文字有更新,往回查發現是針對大小寫的差異提出更新:「Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words」,主要是這兩條:

  • The words have the meanings specified herein only when they are in all capitals.
  • When these words are not capitalized, they have their normal English meanings and are not affected by this document.

然後也更新了引用的部份:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

不過就算是 2017 年之前應該也是這樣讀就是了...

PHP 8 將會移除 XML-RPC,改放到 PECL 內

Twitter 上看到「PHP RFC: Unbundle ext/xmlrpc」這則消息,PHP 官方打算把 XML-RPC (也就是 git repository 裡面的 ext/xmlrpc) 拆出去,移到 PECL

Unbundle ext/xmlrpc (i.e. move it to PECL) without any explicit deprecation.

主要的考慮是在於目前的 library 已經年久失修:

ext/xmlrpc relies on on libxmlrpc-epi, which is abandoned. Even worse, we are bundling a modified 0.51, while the latest version is 0.54.1. This is exacerbated by the fact that the system library is usually built against libexpat, but the bundled library is likely to be built against libxml2 using our compatibility layer.

另外應該也是因為 XML-RPC 用的人不多吧,投票是沒什麼玄念的 50:0,而且在 Packagist 上面也可以翻到一些用 PHP 實做的替代品,拿 xmlrpc 這個關鍵字搜了一下可以看到一些...

RFC8482 廢掉 DNS 查詢的 ANY query 了...

看到 Cloudflare 的「RFC8482 - Saying goodbye to ANY」這篇,裡面提到 RFC8482 廢掉了 ANY 查詢:「Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY」。

The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons.

對 Cloudflare 的痛點主要在於營運上的困難,因為 ANY 回應的 UDP packet size 很大,很容易造成放大攻擊:

把拒絕 ANY 查詢變成標準後,讓 DNS provider 手上多了一把武器可以用。

ACME,RFC 8555

這邊講的是因為 Let's Encrypt 所發明的 ACME 協定,可以協助自動化發憑證的協定。

剛剛看到「Automatic Certificate Management Environment (ACME)」這個頁面,上面標 PROPOSED STANDARD,但點進去的 txt 檔開頭則是 Standards Track 了:

Internet Engineering Task Force (IETF)                         R. Barnes
Request for Comments: 8555                                         Cisco
Category: Standards Track                             J. Hoffman-Andrews
ISSN: 2070-1721                                                      EFF
                                                             D. McCarney
                                                           Let's Encrypt
                                                               J. Kasten
                                                  University of Michigan
                                                              March 2019

不知道是不是兩邊不同步 (或是我對流程有誤會?),但這有一個標準文件可以參考了...

RFC 8446:TLS 1.3

看到 RFC 8446 (The Transport Layer Security (TLS) Protocol Version 1.3) 正式推出了,也就是 TLS 1.3 正式成為 IETF 的標準 (Standards Track)。

Cloudflare 寫了一篇文章「A Detailed Look at RFC 8446 (a.k.a. TLS 1.3)」描述了 TLS 1.3 的特點,有興趣的人可以看一看,尤其是 1-RTT 的部份對效能幫助很大 (0-RTT 因為 replay attack 問題,我應該暫時都不會考慮,要等到有一個合理的防禦模型出來)。

另外一個是 OpenSSL 目前最新版是 1.1.0h,當初就決定要等 TLS 1.3 正式成為標準才會出 1.1.1 (參考「OpenSSL 1.1.1 將支援 TLS 1.3」,這也熬了一年啊... 支援後會就有很多軟體可以直接套用了,可以來期待了。

保護 TLS 的 Hostname

看到「Encrypted Server Name Indication for TLS 1.3」這個,由 FastlyCloudflareApple 的人聯手推出的 draft,想要保護 TLS 連線一開始明文傳輸的 hostname 部分。看起來是透過 DNS 發佈 public key,然後使用者用這把 public key 保護 hostname 的部分...

而 DNS 的部分可以透過 DNS over TLS 或是 DNS over HTTPS 來保護,這樣讓 ISP 沒有任何資訊可以看到 hostname,把暴露的資訊再降低...

來繼續關注這個技術...

RFC 的 Feed...

想說應該有這樣的東西,就找到「https://tools.ietf.org/html/new-rfcs.rss」這頁,本來以為直接就是 RSS feed 了 (因為網址),一打開來發現看起來像是個網頁,結果最上面這樣說明:

Don't panic. This web page is actually a data file that is meant to be read by RSS reader programs.

馬上打開來看 page source code,果然是 XSL

<?xml-stylesheet title="CSS_formatting" type="text/css" href="css/rss.css"?>
<?xml-stylesheet title="XSL_formatting" type="text/xml" href="rss2html.xsl"?>

好久沒看到這個了,大概是十年前想要做到資料與效果分離 (client-side rendering) 的方式...

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)。

JSON 的 Object 裡 Key 重複的問題

tl;dr:不要亂來啦... 這是 UB (Undefined behavior) 的一種。

因為看到這則 tweet,所以去查一下 JSON 的資料:

首先是找標準是什麼。在維基百科的 JSON 條目裡提到了有兩份標準,一份是 RFC 7159,一份是 ECMA-404

Douglas Crockford originally specified the JSON format in the early 2000s; two competing standards, RFC 7159 and ECMA-404, defined it in 2013. The ECMA standard describes only the allowed syntax, whereas the RFC covers some security and interoperability considerations.

ECMA-404 裡面就真的只講語法沒講其他東西,而在 RFC 7159 內的 Object 則是有提到 (重點我就用粗體標起來了):

An object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members). A name is a string. A single colon comes after each name, separating the name from the value. A single comma separates a value from a following name. The names within an object SHOULD be unique.

   object = begin-object [ member *( value-separator member ) ]
            end-object

   member = string name-separator value

An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates.

JSON parsing libraries have been observed to differ as to whether or not they make the ordering of object members visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable in the sense that they will not be affected by these differences.

粗體有描述唯一性,但尷尬的地方在於他用 SHOULD 而非 MUST,所以 library 理論上都要能接受。但後面提到如果不唯一時,行為無法預測 (會到 rm -rf / 嗎?XDDD 最像的應該還是 crash?),所以還是不要亂來啦...

不過如果真的會 crash 的話,應該也會因為 DoS issue 而被發 CVE,所以實務上應該是不會 crash 啦...