attachment

<div dir="ltr"><div>Bad news in TLS-land from a foolish ETSI standard (intentionally <br></div><div>breaking TLS end-to-end security for "authorized" middleboxes).</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>From: <b class="gmail_sendername" dir="auto">Yoav Nir</b> <span dir="auto"><<a href="mailto:ynir.ietf@gmail.com">ynir.ietf@gmail.com</a>></span><br>Date: Sat, Jun 13, 2020 at 1:20 PM<br>Subject: [TLS] Consultation About Assignment of ExtensionTypes<br>To: <<a href="mailto:tls@ietf.org">tls@ietf.org</a>> <<a href="mailto:tls@ietf.org">tls@ietf.org</a>><br></div><br><br><div style="word-wrap:break-word;line-break:after-white-space">Hi.<div><br></div><div>I’m posting this on behalf of the IANA experts for the TLS registries. The IANA experts function is described in RFC  8447 [1].</div><div><br></div><div>We’ve received a request from ETSI to assign three ExtensionType values from the ExtensionType registry [2]. ETSI is the European Telecommunications Standards Institute [3]. Ordinarily requests from other standards organizations are approved as long as they’re not in conflict with current work within the IETF, and for the ExtensionType registry the policy is “Specification Required”.  The reason we are consulting this time is that we can foresee some objections should these assignments appear in the IANA registry.</div><div><br></div><div>So the request is for a part 2 of the Middlebox Security Protocol [4].  You can read it all, but the gist is a protocol between a TLS endpoint and a TLS middlebox that allows the middlebox read, read+delete, or read+delete+write access to the data stream. If this idea is giving you déjà vu, then yes, the TLS working group has considered proposals in that domain in the past, and to put in mildly, did not choose to take them up.</div><div><br></div><div>To re-iterate, the policy for the registry is “Specification Required” and a specification is available. Unless we hear convincing arguments to the contrary, we will approve this allocation. We just prefer to have the kerfuffle before the assignment rather than afterwards.</div><div><br></div><div>Thanks</div><div><br></div><div>Yoav</div><div>(with the IANA expert hat on)</div><div><br></div><div><br></div><div>[1] <a href="https://tools.ietf.org/html/rfc8447" target="_blank">https://tools.ietf.org/html/rfc8447</a></div><div>[2] <a href="https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1" target="_blank">https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1</a></div><div>[3] <a href="https://www.etsi.org/about" target="_blank">https://www.etsi.org/about</a></div><div>[4] <a href="https://docbox.etsi.org/CYBER/CYBER/Open/Latest_Drafts/CYBER-0027-2v020-TLMSP-Transport-Layer-Middlebox-Security-Protocol.pdf" target="_blank">https://docbox.etsi.org/CYBER/CYBER/Open/Latest_Drafts/CYBER-0027-2v020-TLMSP-Transport-Layer-Middlebox-Security-Protocol.pdf</a></div><div><br></div><div><br></div></div>_______________________________________________<br>
TLS mailing list<br>
<a href="mailto:TLS@ietf.org" target="_blank">TLS@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/tls" rel="noreferrer" target="_blank">https://www.ietf.org/mailman/listinfo/tls</a><br>
</div></div></div>