Subject: [TLS] Consultation About Assignment of ExtensionTypes

From: Yoav Nir <[email-masked]>
Date: Sat, 13 Jun 2020 20:20:35 +0300

Hi.

I’m posting this on behalf of the IANA experts for the TLS registries. The IANA experts function is described in RFC  8447 [1].

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.

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.

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.

Thanks

Yoav
(with the IANA expert hat on)

[1] https://tools.ietf.org/html/rfc8447 <https://tools.ietf.org/html/rfc8447>
[2] https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1 <https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1>
[3] https://www.etsi.org/about <https://www.etsi.org/about>
[4] https://docbox.etsi.org/CYBER/CYBER/Open/Latest_Drafts/CYBER-0027-2v020-TLMSP-Transport-Layer-Middlebox-Security-Protocol.pdf <https://docbox.etsi.org/CYBER/CYBER/Open/Latest_Drafts/CYBER-0027-2v020-TLMSP-Transport-Layer-Middlebox-Security-Protocol.pdf>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 19 Jun 2020 01:24:05 +0100

Hiya,

I think these are 16 bit code points?  If so, I would
barf slightly less if we could allocate 0x0bad every
time.

I do think signalling opprobrium somehow would be right
here. Not sure how best we ought do that though tbh.

Cheers,
S.

On 13/06/2020 18:20, Yoav Nir wrote:
> Hi.
> 
> I’m posting this on behalf of the IANA experts for the TLS
> registries. The IANA experts function is described in RFC  8447 [1].
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Thanks
> 
> Yoav (with the IANA expert hat on)
> 
> 
> [1] https://tools.ietf.org/html/rfc8447
> <https://tools.ietf.org/html/rfc8447> [2]
> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1
> <https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1>
>
> 
> [4]
> https://docbox.etsi.org/CYBER/CYBER/Open/Latest_Drafts/CYBER-0027-2v020-TLMSP-Transport-Layer-Middlebox-Security-Protocol.pdf
> <https://docbox.etsi.org/CYBER/CYBER/Open/Latest_Drafts/CYBER-0027-2v020-TLMSP-Transport-Layer-Middlebox-Security-Protocol.pdf>
>
> 
> 
> 
> 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 18 Jun 2020 17:36:41 -0700

> here. Not sure how best we ought do that though tbh.

You could write an I-D and see how it looks ;)

-Ben

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 19 Jun 2020 02:26:03 +0100

Hiya,

> You could write an I-D and see how it looks ;)

I guess. Not sure I have the time right now for
draft-not-green though:-)

S.

---

From: Rob Sayre <[email-masked]>
Date: Thu, 18 Jun 2020 22:26:57 -0700

On Sat, Jun 13, 2020 at 10:20 AM Yoav Nir <[email-masked]> wrote:

>
> 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.
>

If the IANA experts feel the 99 page PDF is "sufficiently clear and
technically sound" [1], then it should appear in the registry. [2]

It seems like it should appear with a "Recommended" value of "No", and no
value in the TLS 1.3 column, since the document says "The Middlebox
Security Protocol builds on TLS 1.2". [3]

Is that what's being proposed?

thanks,
Rob

[1] https://tools.ietf.org/html/rfc8126#section-4.6
[2]
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1
[3]
https://docbox.etsi.org/CYBER/CYBER/Open/Latest_Drafts/CYBER-0027-2v020-TLMSP-Transport-Layer-Middlebox-Security-Protocol.pdf
(Section 1, scope)

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 19 Jun 2020 13:41:06 +0000

In my view, as one of the three designated experts, we already have the only channel we need, it's the "approved" column.

Anything else -- anything more -- runs counter to our principal of interop over all.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 19 Jun 2020 18:02:51 +0000

*   It seems like it should appear with a "Recommended" value of "No", and no value in the TLS 1.3 column, since the document says "The Middlebox Security Protocol builds on TLS 1.2". [3]

  *   Is that what's being proposed?

Yes.

---

From: Rob Sayre <[email-masked]>
Date: Fri, 19 Jun 2020 17:39:45 -0700

On Fri, Jun 19, 2020 at 11:02 AM Salz, Rich <[email-masked]> wrote:

>
>    - It seems like it should appear with a "Recommended" value of "No",
>    and no value in the TLS 1.3 column, since the document says "The Middlebox
>    - Is that what's being proposed?
>
>
>
> Yes.
>

I am in favor of this registration.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 20 Jun 2020 14:04:19 -0700

On Fri, Jun 19, 2020 at 11:03 AM Salz, Rich <rsalz=
[email-masked]> wrote:

> _________________

I believe this is the right outcome. While I am not particularly a fan of
this protocol and I believe it would likely be better if ETSI abandoned it,
the purpose of the 8447 policy is that we do not use code point assignment
to discourage the use of  protocol extensions we don't approve of.

-Ekr

______________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>