財團法人台灣網路資訊中心因公出國人員報告書

九十六年十二月十日

報告人

 

陳式偉

楊禎葆

服務單位及職稱

資深工程師

工程師

出國期間

九十六年十二月二日至

九十六年十二月七日

出國地點

加拿大 溫哥華

出國事由

參加第七十次 IETF溫哥華會議

報告書內容應包含:

一、出國目的

二、考察、訪問過程

三、考察、訪問心得

四、建議意見

五、其他相關事項或資料

(內容超出一頁時,可由下頁寫起)

   

聲 明 欄

本出國報告書同意貴中心有權重製發行供相關研發目的之公開利用。

          授權人:                    (簽章)

附一、請以「A4」大小紙張,橫式編排。出國人員有數人者,依會議類別或考察項目,彙整提出報告。

二、請於授權聲明欄簽章,授權本中心重製發行公開利用。


一、出國目的

第七十次IETF會議於九十六年十二月二日至九十六年十二月七日在加拿大溫哥華舉行。此次會議為期六天,而中心參加之主要目的為參加 EAI WG (Working Group) 標準討論EAI (Email Address Internationalization ),及參加 DNS 相關之 WG 會議,並參與會中心之相關議題(DNSOP/DomainKey) 以了解其發展。

二、考察、訪問過程

此次會議雖期程共六天,行程安排,我們僅參加五天的會議,重點參加必要之 WG,所以共參加了三個 WG分別為 DKIMEAIDNSOP

所到第一日是晚上,依慣例此日為 New Comer Training,因為過去參加過,故我們沒有參加此一教育訓練課程,而稍做整埋後,稍加了解了一下圍環境。次日,正式開始一系列之 Working Group 會議,由於會議是同一時間有多個 WG 同时舉行,故我們僅選擇與中心核心之相關問題參加,故共參加了三場不同之主題。

三、考察、訪問心得

 

DKIM WG (Domain Keys Identified Mail)

DKIM WG 主要在設計一套 Email 認證的方式,以減少 Spam Mail 的判讀問題,這個做法主要在 MTA 端發生,而不影響目前的 MUAMTA 在發送信件時以自己的 Private key 對表頭 (Mail Header) 加密計算,產生一組簽章,收信的 MTA 在收到信件時,以 DNS 查詢的方式取得發送端的 sha publick key,進行還原處理,處理後與發送端的簽章進行比對是否一致。其處理原則在於以 Public Key Sign 同樣的表頭 (h=XXX)以取得相同的簽章值,若相同表示 Sender Domain 是正確的,以達到 antispam 所需的 Domain Key Verify 之功能。

這個做法其實和 SPF 有點類似,雖然 SPF 沒有那麼多的行為定義,但相對而言 SPF 則直覺許多,DKIM 需要有簽章及驗證動作,可能會使用到較多的系統資源,對於惡意的攻擊容易形成 DOS 狀況,這是目前 DKIM 最大的缺點,而表頭處理確實能有效驗證發送者身份,只要進行 DKIM 的檢查,即可決定對進件的處理行為是拒收或接收。

本次 DKIM WG 會議主要討論之重點仍然是 SPP ( Signing Practices Protocol)SPP 是一個第三方資訊主要在說明這個Domain Signing 政策為何。本次會議之前 Submit  SPP Draft 新增了 Handling 之功能,此功能主要在處理可疑的 Messages 時,處理的原則為何;未預定代表 default ,對於可疑的 Spam 則進行 bypass 處理,若設為 deny,則對於可疑的 Mail則進行攔截處理。這項的處理原則完全是由 Receiver端來控制的,以便可以增加更多的安全性。此外,針對SPP 相關的 issues本次會議也有了許多相關的決議:
n         #1382: New Resource Record Type: 使用新的 DNS Type 來定義 SPP 相關內容,因為現有的 Draft 仍未提及故需更新。
n         #1399: Clarify i= vs. SSP: 若有 SPP 則使用 SPP 之定義,若沒有 SPP 相關之定義則使用 i= 來定義 From Tag
n         #1402: Applicability of SSP to Subdomains: 建議最多僅使用一層之 Subdomain,以避免不必要的 Dns search path及減少複雜度。
n         #1512: SSP should not link all and third parties: Receivers可自行決定連結的第三方,連結的第三方不建議再連結。〕
n         New issue: Responsibility vs. ValiditySPP 必需對於 From 有明確的定義,即使原來的信件巳標明了 DKIM 相關的 From tag
 
會議上還對 SPP 進行了一次系統介紹,其內容主要是說明 SPP 的好處,個人覺得SPP 應是對 DKIM Overview 的補強,以便解決原來 DKIM 所存在的缺點,並對第三方的存取進行了一定的規範,由其對於 From: 的相對說明極為清楚,以避免相關之問題。同時亦報告了現在 Internet  DKIM 的運作情形及測試結果,有許多的大型企業經將 DKIM 實作到公司的 Mail Service 中,並且有許多的 MTA  antispam 亦對 DKIM 進行的實作。此外針對此一實作情況所發現到的問題近一探討,對於理清 DKIM 在推廣上所遇到的問題亦有很大的幫助。會議上亦對現場與會者進行了 DKIM 的實作及運作的調查,以了解各方的意見與看法。此外,draft-kucherawy-sender-auth-header-09也進行了必要的更新及新增 DKIM 的相關表頭Authentication-Results來儲存 DKIM的驗證結果。而作者也預計於本次會議後另外撰寫 smtp  extension 版及IMAP 相關的 Draft,因為這些都關係著 DKIM 的相關應用。
 

DNSOP WG (Domain Name Service Operation)

此次 Working Group 會議討論了關於 IPv6 to IPv4 的穿透時的反解問題(draft-huston-6to4-reverse-dns-07.txt)。以及 Reolsver 可能影起的安全問題 (draft-ietf-dnsop-reflectors-are-evil-04.txt),另外也建議在新的 DNS 版本開發時,對於特殊用途的 IP 採用 Default zone 的方式來處理(draft-ietf-dnsop-default-local-zones-03.txt),因為這個問題主要是因為像 Private IP broadcast/multicast 等問題(包含 IPv6),這些問題影響了 Root Server 的查詢壓力。此外有四篇 Draft 進入了 Last Call 的狀態,分別是

draft-ietf-dnsop-as112-under-attack-help-help-01.txtdraft-ietf-dnsop-as112-ops-01.txtdraft-ietf-dnsop-respsize-08.txtdraft-ietf-dnsop-reverse-mapping-considerations-05.txt對於一些尚無普遍共識的 Draft 則先不予討論,待於 mailing list 上有相當探討後再列入日後議程來討論 (draft-larson-dnsop-trust-anchor-02.txtdraft-ietf-dnsop-resolver-priming-00.txt)

 

EAI WG (Email Address Internationalization Working Group)

這個 WG 是中心目前參加 IETF 會議中的重點項目,主要在討論 Email Local-Part 中使用 UTF8 編碼的一些方法,尤於影響層面蠻廣的,所以細節問題亦不少。重點如下:

1.          本次會議共有三篇 Draft 進入了 Last Call

1.1      draft-ietf-eai-utf8headers-08.txt: TWNIC 所撰寫,主要說明表頭 (mail headerMIME header) 的變動及處理原則。

1.2      draft-ietf-eai-dsn-05.txt: Alex 所選寫,說明原來的 SMTP Extension DSN EAI 如何處理訊息的封裝。

1.3      draft-ietf-eai-smtpext-09.txt: CNNIC 所選寫,說明 EAI ESMTP 的處理原則及配套的 ALT-ADDRESS

1.4      TWNIC utf8header: Draft 目前則有兩個 Issues,分別是:

ü          #1507: UTF8HDR/DSN: Remove NO-WS_CTL from specification: 會議上表決方案,最後以 RFC 2822bis 中的 text ABNF 為此 Draft text 內容,此方案需等 RFC 2822bis 的修正版公布。

ü          #1518: UTF8HDR 4.1: Normalization isn't talked about. : 此問題經由現場提問後,與會者決定採用 John Klensin utf8 draft 的建議並經由表決通過。

2.          John Klensin 所撰寫之 framework 可能存在一些盲點,建議對Normalization之問題進行適當之修改

3.          POP/IMAP/Mailing-List draft 因大家較少討論,不過也沒有什麼反對意見,在現場徵集實作者有人願意針對這些 Protocol 作化,故待實作有一明確結果後,於下次會議再討論之;同時,因為 POP/IMAP Draft up-convert 的論述,現場與會者看法是這一較不需要,所以更新的 Draft 不需提及這個問題

4.          JPRS 所撰寫之downgraded 對於 DKIM 的部份仍有少許疑義,有些人建議單獨對 DKIM 另成一文來描述這些問題和方法,以避免卡住現有的 Draft Last Call,而會場上雖進行了表決2:0,但因投票數過少故尚無一定共識,故留待 eai mailing list 上再進行較深入的討論,以取得普遍的共識後再決定是否單獨對 DKIM+Downgraded 的狀況另外撰寫 Draft

5.          由於目前 EAI 使用了 <UTF8_Address <addr_spec>> 來表示 EAI Email address,此表示法與現有的 IRI (Ex: mailto) 存在一些衝突,故 Working Group 需橫向和 Mailto IRI 的作者進行連絡,請其修改IRI 的部份表示法以達到一般的 Email 連結也可以使用 EAI 的表示法。

6.          Working Group 希望可以在明年底達成任務,讓所有的 Draft RFC 化,以完成 Email UTF8 化之目的。

 

由於 EAI Working Group 成立二年了,這兩年來除了 framework 成為了 RFC 外,有三篇 (-dns-utf8header-smtpext) 進入 Last Call,並且 mailing list/pop/imap 很有可能於下次會議前進入 Last Call,預估整個 Working Group 應該可以於明年底或後年初完成所有的工作。

 

 

下次 IETF 會議將於明年三月九日三月十四日於美國費城舉行,對於本次會議未決之事項先於 mailing-list 上討論之,若仍未決於下次會議再進行討論與決議。
 
 
 

四、建議意見

1.         持續追踪 mailing list 上之討論及配合事項。
2.         可適時將中心所實作之 EAI 環境適時回報至 EAI Design Team

3.          DNSOP WG 中之 AS122 及部份 IP 反解設定可於日後中心相關教育訓練多加推廣。

 

 

五、其他相關事項或資料

有關第七十次IETF會議議程及相關會議資料請參考(Agenda/ Session/ Presentations)

https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=70