องค์กรวางมาตรฐานอินเทอร์เน็ต IETF (Internet Engineering Task Force) ฉลองครบรอบ 30 ปีนับจากการประชุมครั้งแรกในวันที่ 16-17 มกราคม 1986 ที่มีผู้เข้าร่วม 21 คน และอินเทอร์เน็ตมีคอมพิวเตอร์เชื่อมต่อทั้งหมดหลักพันเครื่อง

ความสำเร็จและความล้มเหลวของ IETF มีมากมาย มาตรฐาน HTTP, TLS, และ HTTPS เป็นรูปเป็นร่างในรูปแบบเอกสารที่ทุกคนเข้าใจตรงกันได้ก็ด้วยกระบวนการของ IETF และยังมีการปรับปรุง และรักษาความเข้ากันได้กับโปรโตคอลเดิมเรื่อยมา

ร่างเอกสาร IETF นำเสนอโดยเสนอให้โค้ด HTTP 451 เป็นโค้ดสำหรับการบล็อคเว็บสำหรับรัฐบาล โดยเปิดช่องทางให้เปิดเผยหน่วยงานที่สั่งบล็อคเว็บและช่องทางติดต่อกลับ

ชื่อเต็มของ HTTP 451 คือ "Unavailable For Legal Reasons" ตัวเลขรหัส 451 น่าจะล้อเลียนมาจากหนังสือเรื่อง Fahrenheit 451 ที่พูดถึงโลกอนาคตที่รัฐบาลปิดกั้นการรับรู้ข้อมูลด้วยการเผาหนังสือ

ตัวอย่างหน้าเว็บที่ถูกบล็อคดังนี้

BLAKE2 เป็นอัลกอริทึมแฮชที่เข้าแข่งขันให้เป็นมาตรฐาน SHA-3 ของ NIST (องค์กรมาตรฐานทางเทคโนโลยีของสหรัฐฯ) และเข้ารอบไปถึงรอบสุดท้ายที่อัลกอริทึมเข้ารอบ 5 อัลกอริทึม แม้สุดท้าย Keccak จะเป็นผู้ชนะได้เป็นมาตรฐาน SHA-3 แต่ผู้สร้าง BLAKE2 ก็เสนอให้เป็นมาตรฐานทางเลือกหนึ่งของ IETF

กระบวนการเสนอมาตรฐานมีการเสนอมาตั้งแต่ต้นปีที่ผ่านมา ตอนนี้เอกสารก็ตีพิมพ์เป็น RFC7693 เรียบร้อยแล้ว

กูเกิลและยาฮูประกาศรองรับมาตรฐาน DMARC ที่เสนอโดยยาฮู เพื่อยืนยันว่าผู้ส่งเป็นเจ้าของบัญชีจริง มาตรฐานนี้ผ่านเป็น rfc7489 เมื่อต้นปีที่ผ่านมา

ทั้งสองบริษัทประกาศร่วมกันที่จะรองรับมาตรฐานนี้โดยเร็ว ทางฝั่งยาฮูนั้นจะรองรับมาตรฐานนี้บนโดเมน ymail.com และ rocketmail.com ตั้งแต่เดือนพฤศจิกายนนี้ หลังจากเปิดใช้งานบน Yahoo! Mail ไปตั้งแต่ปีที่แล้ว ส่วนกูเกิลจะเริ่มรองรับเต็มรูปแบบภายในเดือนมิถุนายนปีหน้า

มาตรฐาน HTTP/2 แก้ปัญหาของ HTTP 1/1.1 ไปหลายอย่าง ทำให้ข้อมูลสามารถส่งได้อย่างมีประสิทธิภาพดีขึ้นมากโดยเฉพาะการส่งข้อมูลขนาดเล็ก ตอนนี้ Mark Nottingham ประธานกลุ่มพัฒนา HTTP/2 ก็โพสข้อเสนอใหม่สู่ IETF เสนอให้มีส่วนเสริมของ HTTP/2 เพื่อใช้เป็นโปรโตคอลสำหรับ VPN

การใช้ VPN ผ่าน HTTP/2 จะมีข้อดีสำคัญคือการดักจับข้อมูลเพื่อบล็อคบริการ VPN จะทำได้ยากขึ้น เพราะภายนอกแล้วมันจะเหมือนกับ HTTP/2 ทั่วไปทุกประการ

ข้อเสนอนี้เป็นข้อเสนอเบื้องต้นที่ยังแทบไม่มีรายละเอียดอะไรนอกจากการเริ่มต้นการเชื่อมต่อ ผู้เขียนข้อเสนอระบุว่าต้องเพิ่มเติมทั้งส่วนการยืนยันตัวตน และแนวทางการส่งวงเครือข่ายที่สามารถเราท์ไปได้

IETF ร่วมมือกับกลุ่ม IEEE 802 กลุ่มวางมาตรฐาน LAN/Wi-Fi ประกาศผลการทดสอบการรักษาความเป็นส่วนตัวของ Wi-Fi ที่ทดสอบมาแล้วสามครั้งตั้งแต่ปลายปีที่แล้ว และประกาศว่าทั้งสองกลุ่มยืนยันจะรักษาความเป็นส่วนตัวของผู้ใช้

รายการการทดสอบทั้งสามครั้งระบุถึงแนวทางที่เป็นไปได้ที่จะรักษาความส่วนตัวของผู้ใช้ Wi-Fi เช่น การสุ่ม MAC ระหว่างการหาเครือข่าย (แบบเดียวกับที่แอปเปิลทำใน iOS 8), สุ่ม MAC เมื่อเชื่อมต่อสำหรับอุปกรณ์เคลื่อนที่, สุ่ม SSID สำหรับการแชร์ 3G, เข้ารหัสข้อมูลมากขึ้นรวมไปถึงการเข้ารหัสข้อมูลการจัดการเครือข่าย ไม่ใช่เฉพาะข้อมูลที่ส่ง

HTTP/2 เตรียมประกาศเป็นมาตรฐานมาตั้งแต่เดือนกุมภาพันธ์ เมื่อวานนี้ทาง IETF ก็เผยแพร่เอกสารเป็น rfc7540 เป็นทางการแล้ว

RFC หรือ request for comments เป็นเอกสารที่ไม่ได้ขอความเห็นตามชื่อของมันเท่าใดนัก เพราะเอกสารที่ประกาศเป็น RFC จะเป็นมาตรฐานขั้นสุดท้ายที่ไม่มีการแก้ไขอีก จะมีเฉพาะการประกาศ RFC ใหม่เพื่อทดแทน RFC เดิมเท่านั้น

ที่มา - The Register

เมื่อวันที่ 17 กุมภาพันธ์ที่ผ่านมากลุ่มขับเคลื่อนวิศวกรรมอินเทอร์เน็ต หรือ IESG ซึ่งเป็นหน่วยงานย่อยที่ทำหน้าที่ผลักดันมาตรฐานบนอินเทอร์เน็ตได้อนุมัติการส่งร่างมาตรฐาน HTTP/2 ขึ้นประกาศเป็นมาตรฐานใหม่แล้วครับ

โพรโทคอล HTTP/2 (เดิมเรียกว่า HTTP/2.0) ถูกร่างขึ้นจากโพรโทคอล SPDY/2 ที่กูเกิลพัฒนามาระยะเวลาหนึ่งแล้ว ซึ่งมีการเปลี่ยนแปลงมาตรฐานจาก HTTP/1.1 ที่ถูกประกาศใช้งานเมื่อปี ค.ศ. 1999 เป็นจำนวนมาก โดยส่วนใหญ่เป็นการปรับปรุงประสิทธิภาพ ที่ทำให้ช่วยเพิ่มความเร็วการเชื่อมต่อ ปรับปรุงวิธีการเรียกใช้งานให้สามารถร้องขอข้อมูลหลายๆ ชิ้นได้ในครั้งเดียว ทำให้ลดภาระฝั่งนักพัฒนา เช่นการรวมไฟล์ css, js หรือการทำ css sprite ไปได้ด้วยครับ

มาตรฐาน ASCII ที่เราใช้พิมพ์ภาษาอังกฤษในคอมพิวเตอร์ทุกวันนี้ นับตั้งแต่ตัวอักษร, เครื่องหมาย, คำสั่ง เช่น ลบหรือขึ้นบรรทัดใหม่ ล้วนถูกกำหนดไว้ในตาราง ASCII ที่เขียนกำหนดไว้ใน RFC20 โดย Vint Cerf มาตั้งแต่ปี 1969 ผ่านมา 46 ปีตอนนี้ RFC20 ได้รับสถานะ "มาตรฐานอินเทอร์เน็ต" เต็มรูปแบบจาก IETF แล้ว

เหตุที่ RFC20 เพิ่งได้รับสถานะมาตรฐานอินเทอร์เน็ตเพราะมันถูกเขียนมาก่อนจะมีกระบวนการรับรองมาตรฐานอินเทอร์เน็ต ทำให้เอกสารอยู่ในสภาพไร้สถานะใน IETF มาโดยตลอด

เอกสาร draft-ietf-tls-prohibiting-rc4-01 ที่เสนอโดยไมโครซอฟท์กำลังเข้าสู่กระบวนการสุดท้ายก่อนออกเป็นมาตรฐาน เพื่อยกเลิกการใช้กระบวนการเข้ารหัสแบบ RC4 ในการเชื่อมต่อแบบ TLS ทุกรูปแบบ

มาตรฐานนี้ระบุว่าไคลเอนต์ทุกตัวจะต้องไม่รองรับการเข้ารหัสแบบ RC4 ในเมสเสจ ClientHello อีกต่อไป ขณะที่เซิร์ฟเวอร์ก็จะไม่เสนอ RC4 ให้ไคลเอนต์เลือก ที่สำคัญคือหากไคลเอนต์ระบุว่าเชื่อมต่อได้เฉพาะการเข้ารหัสแบบ RC4 เซิร์ฟเวอร์จะต้องยกเลิกการเชื่อมต่อทันที

ที่งาน Internet Governance Forum เมื่อเช้านี้ ผมได้มีโอกาสพบกับ Jari Arkko ประธานคณะทำงานวิศวกรรมอินเทอร์เน็ต (รู้จักกันในนาม IETF หรือ Internet Engineering Task Force) เลยได้มีโอกาสสัมภาษณ์สั้นๆ เกี่ยวกับเรื่องของมาตรฐาน HTTP 2.0 ครับ

Jari Arkko ปัจจุบันทำงานอยู่ที่ Ericsson โดยอยู่ในสายงายวิจัยของบริษัท และเคยเป็นประธานคณะกรรมการดำเนินงานผลักดันด้านวิศวกรรมอินเทอร์เน็ต (Internet Engineering Steering Group: IESG) โดยเขารับหน้าที่เป็นประธาน IETF เมื่อเดือนมีนาคมปีที่แล้ว (อ่านประวัติโดยย่อได้ที่นี่)

นโยบายการเข้ารหัสที่เริ่มใช้เป็นมาตรฐานกับ HTTP 2.0 จะขยายออกไปยังมาตรฐานตัวอื่นๆ หรือไม่ครับ?

เมื่อเช้านี้ตามเวลาท้องถิ่น ณ กรุงอิสตันบูล ประเทศตุรกี ที่งานประชุม Internet Governance Forum ได้มีการสนทนาแลกเปลี่ยนในประเด็นเรื่องของ Internet of Things (IoT) ในเชิงนโยบายและการปฏิบัติ โดยมีผู้เข้าร่วมที่เป็นตัวแทนจากทั้งภาคเอกชน ภาควิชาการ เจ้าหน้าที่เชิงเทคนิค และภาคประชาสังคมบนเวที

สมาชิก Blognone คงทราบกันดีอยู่แล้วว่า "ที่อยู่อีเมล" ต้องสะกดด้วยตัวอักษรในภาษาละตินเท่านั้น (ASCII) ซึ่งการใช้งานอาจไม่ตอบโจทย์ผู้ใช้ที่พูดภาษาอื่นๆ เท่าไรนัก

เมื่อปี 2012 Internet Engineering Task Force (IETF) แก้ปัญหานี้โดยออกมาตรฐานเพิ่มเติม ให้ที่อยู่อีเมลสามารถสะกดด้วยตัวอักษรที่อยู่นอกกลุ่ม ASCII ได้ โดยยึดตามมาตรฐานตัวอักษร UTF-8 ที่มีอยู่แล้ว แต่การใช้งานจะต้องเพิ่มส่วนต่อขยายให้โพรโทคอลอีเมล SMTP ด้วย (มาตรฐานอีเมลฉบับเพิ่มเติมสามารถอ่านได้จาก RFC-6530)

IETF หน่วยงานออกมาตรฐานอินเทอร์เน็ตกลายเป็นองค์กรที่มีอิทธิพลสูงขึ้นเรื่อยๆ ในช่วงหลัง จากการออกมาตรฐานสำคัญ เช่น HTTP 2.0 หลายมาตรฐานเกี่ยวข้องกับความปลอดภัยของผู้ใช้จำนวนมาก ต้นทุนของผู้ให้บริการอินเทอร์เน็ต และผลประโยชน์ของบริษัทเอกชนและรัฐบาลทั่วโลก หากใครได้ตามข่าวการออกมาตรฐานแต่ละครั้ง การถกเถียงใน mailing list ของ IETF จะยาวนับร้อยนับพันข้อความ และหลายครั้งที่ประธานกลุ่มทำงานระบุว่าน่าจะได้ข้อสรุปก็จะมีข้อถกเถียงกันต่อไปเรื่อยๆ อีกพักใหญ่โดย IETF ไม่ได้ยึดเสียงโหวตเพื่อหาข้อสรุปให้มาตรฐาน ทำให้น่าสงสัยว่าสุดท้ายแล้วมาตรฐานต่างๆ นั้นออกมาได้อย่างไร ตอนนี้ก็มีเอกสาร RFC7282 หัวข้อ "On Consensus and Humming in the IETF" มาอธิบายถึงกระ

มาตรฐาน TLS 1.3 มีข้อเสนอที่ได้รับเสียงสนับสนุนในการประชุมครั้งที่ผ่านมา (IETF 89) ว่าจะเริ่มถอดกระบวนการเข้ารหัสที่ไม่รับประกันความเป็นความลับในอนาคต (forward secrecy) ออกจากมาตรฐาน ได้แก่การแลกกุญแจลับแบบ RSA

Vidya Narayanan วิศกรของกูเกิลที่ทำงานร่วมกับกลุ่ม IETF ตั้งแต่ปี 2003 ถึงปี 2010 เธอเคยถูกเสนอชื่อเข้าเป็น Internet Architecture Board (IAB) แต่เธอปฎิเสธตำแหน่งและลาออกจาก IETF หลังจากนั้นไม่นาน ตอนนี้เธอมาเขียนบทความอธิบายสาเหตุที่เธอลาออกจาก IETF ลงใน GigaOM

เธอระบุว่ากระบวนการพัฒนามาตรฐานไม่ได้เร็วขึ้นเลยในช่วงหลายปีที่ผ่านมา ขณะที่กระบวนการนำซอฟต์แวร์ไปใช้จริงนั้นเร็วขึ้นอย่างมาก กระบวนการพัฒนามาตรฐานกลับกลายเป็นสนามประลองกำลังระหว่างกลุ่มผลประโยชน์ที่มีวาระของตัวเองมากมาย

ทีมวิศวกรจาก AT&T ส่งร่างมาตรฐาน "Explicit Trusted Proxy in HTTP/2.0" เปิดทางให้ผู้ให้บริการอินเทอร์เน็ตสามารถดักฟังข้อมูลได้ทังหมดแม้จะเป็นข้อมูลเข้ารหัส HTTPS ก็ตาม

AT&T เป็นผู้ให้บริการอินเทอร์เน็ตรายใหญ่ในสหรัฐฯ เหตุผลการขอสิทธิ์เข้าถึงข้อมูลที่เข้ารหัสไว้ ก็เพื่อทำให้ผู้ให้บริการอินเทอร์เน็ตสามารถแคชข้อมูลไว้ในพรอกซี่ได้ เพื่อลดปริมาณข้อมูลที่ต้องส่งเข้าออกผ่านอัพลิงก์ที่มีราคาแพง

ร่างมาตรฐานระบุให้พรอกซี่ต้องขออนุญาตผู้ใช้เพื่อถอดรหัสอย่างเป็นทางการ

Mark Nottingham ประธานกลุ่มพัฒนามาตรฐาน HTTP/2 ของ IETF เขียนบล็อกระบุว่ามาตรฐาน HTTP/2 นั้นใกล้จะสมบูรณ์แล้ว เขาจึงมาตอบคำถามว่าหลังจากมี HTTP/2 แล้วจะมีอะไรเกิดขึ้นบ้าง

หลังจากงาน IETF-88 การโต้เถียงประเด็นความปลอดภัยของ HTTP 2.0 ยังคงไม่ได้ข้อสรุป โดยมีแนวทางสำคัญ การเข้ารหัสเท่าที่เป็นไปได้ และการบังคับเข้ารหัสเต็มรูปแบบ

กระบวนการเข้ารหัสเท่าที่เป็นไปได้ (opportunistic encryption) คือการเปิดให้เบราว์เซอร์พยายามเข้ารหัสก่อนเสมอ แม้จะไม่มีใบรับรองดิจิตอลเต็มรูปแบบก็ตาม เบราว์เซอร์ก็ยังยอมรับการเข้ารหัสกับเซิร์ฟเวอร์เหล่านี้ แต่จะแสดงผลกับผู้ใช้ว่ากำลังใช้งานเป็น HTTP และไม่แจ้งผู้ใช้ว่ากำลังเข้ารหัสอยู่

IETF เตรียมการประชุมเพื่อพิจารณามาตรฐาน HTTP 2.0 ถึงคราวเปลี่ยนแปลงอีกครั้ง เมื่อข่าว NSA จำนวนมากสร้างความวิตกไปทั่วโลก จากเดิมมาตรฐาน HTTP 2.0 เคยตกลงกันในประเด็นการเข้ารหัสเมื่อการประชุม IETF-83 ช่วงมีนาคมปี 2012 ว่าจะไม่มีการบังคับให้เข้ารหัส แต่ในการประชุม IETF-88 สัปดาห์หน้า ประเด็นนี้จะถูกยกขึ้นมาถกกันอีกครั้ง

นอกจากมาตรฐาน HTTP ที่น่าจะมีผลต่อคนทั่วไปเป็นวงกว้างแล้ว มาตรฐานอื่นๆ ในอินเทอร์เน็ตกำลังถูกยกขึ้นมาว่าควรมีการเข้ารหัสเพิ่มเติมหรือไม่ เช่น มาตรฐาน RTCWeb สำหรับการเชื่อมต่อผ่านเบราว์เซอร์

มาตรฐาน HTTP 2.0 กำลังพัฒนาร่วมกันหลายหน่วยงาน ที่สำคัญคือมีทั้งไมโครซอฟท์และกูเกิล ตอนนี้มาถึงดราฟท์ที่ 04 (เริ่มจากดราฟท์ที่ 00) โดยความเปลี่ยนแปลงสำคัญในรุ่นนี้คือการรองรับโปรโตคอลแบบไบนารี คาดว่าจะเริ่มทดสอบความเข้ากันได้ของโปรโตคอลภายในเดือนสิงหาคมนี้ และน่าจะประกาศมาตรฐานได้จริงภายในปีหน้า

ฟีเจอร์อื่นๆ ที่เพิ่มเข้ามาใน HTTP 2.0 คือ การมัลติเพล็กซ์การเชื่อมต่อทำให้การร้องขอข้อมูลหลายๆ ชุดสามารถรวมเข้าไว้ในการเชื่อมต่อ TCP เดียวกันได้ และยังสามารถจัดสำดับความสำคัญของการเชื่อมต่อแต่ละชุดได้

เทคโนโลยี VP8 เป็นกระบวนการบีบอัดวิดีโอที่กูเกิลไปซื้อมาจากบริษัท On2 โดยเป็นการซื้อทั้งบริษัท และพยายามทำให้เป็นฟอร์แมตมาตรฐานสำหรับอินเทอร์เน็ต (เสนอเป็น RFC6386) และตอนนี้โนเกียก็ยื่นเรื่องต่อ IETF ระบุว่าตัวเองเป็นเจ้าของสิทธิบัตรทั้งสิ้น 64 รายการ และคำขอรับสิทธิบัตรอีก 22 รายการที่คาบเกี่ยวกับ VP8

ต่อเนื่องจากข่าวเก่าเรื่องการตั้งคณะทำงานขึ้นมาร่างมาตรฐาน HTTP/2.0 ตอนนี้คณะทำงานที่ว่านี้เป็นรูปเป็นร่างขึ้นมาแล้วครับ เมื่อทาง IESG ที่เป็นหน่วยงานย่อยใน IETF หรือ Internet Engineering Task Force ที่เป็นหน่วยงานออกแบบร่างและรับรองมาตรฐานทางอินเทอร์เน็ตได้ให้อนุญาตให้มีคณะทำงานร่างมาตรฐาน HTTP/2.0 อย่างเป็นทางการแล้วครับ

มาตรฐาน OAuth ที่ได้รับความนิยมอย่างมากในตอนนี้และกำลังร่าง OAuth 2.0 อาจจะมีปัญหาใหม่ เมื่อ Eran Hammer หนึ่งในผู้เขียน OAuth เวอร์ชั่นแรกและมีส่วนร่วมในการร่างมาตรฐานใหม่มาตลอดสามปีประกาศลาออก และถอนชื่อออกจากมาตรฐาน

เขาระบุว่า OAuth 2.0 เป็นสิ่งที่น่าผิดหวังที่สุดในชีวิตการทำงานของเขา, มันเป็นมาตรฐานที่แย่, WS-* เป็นสิ่งที่แย่ ความแย่นี้อยู่ในระดับที่เขาไม่อยากให้ชื่อของเขาไปเกี่ยวข้องกับมันอีกต่อไป

มาตรฐาน OAuth เข้าไปเป็นคณะทำงานใน IETF โดยหวังจะเชื่อมระหว่างโลกของเว็บกับโลกองค์กรเข้าด้วยกัน แต่ในช่วงหลังทีมงานเดิมใน OAuth 1.0 ก็ลาออกเกือบหมด ทิ้งไว้แต่ทีมงานที่ถูกส่งมาจากองค์กรต่างๆ เท่านั้น

มาตรฐาน HTTP Strict Transport Security (HSTS) เป็นส่วนเสริมของ HTTP/HTTPS ที่เปิดให้เว็บ "บังคับ" ให้เบราว์เซอร์เชื่อมต่อกับเว็บแบบเข้ารหัสเสมอ แม้ผู้ใช้จะไม่ระบุว่าต้องการใช้ HTTPS ก็ตามที กระบวนการนี้ทำให้ไม่มีการเชื่อมต่อแบบ HTTP ที่ดักฟังได้เลย ช่วยลดความเสี่ยงของผู้ใช้ลง

ที่ผ่านมามาตรฐานนี้ยังอยู่ในช่วงรับฟังความคิดเห็น แม้ว่ากูเกิลจะนำไปใช้งานในโครมอยู่นานแล้วก็ตาม โดยการโจมตีผ่านใบรับรองของ DigiNotar รอบล่าสุดเว็บจำนวนมากของกูเกิลก็รอดมาได้เพราะ HSTS

กระบวนการให้ความเห็นรอบสุดท้ายจะต้องส่งความเห็นไปยัง IETF ภายในวันที่ 25 นี้ และการโหวตจะมีขึ้นใน "ไม่กี่สัปดาห์" ข้างหน้า