Subject: URN request for HbbTV

From: Paul Higgs <[email-masked]>
Date: Tue, 2 Sep 2014 12:08:11 +0000

Hello

In accordance with the instructions RFC 3406, the HbbTV Association kindly requests IETF to approve the assignment of "hbbtv" as a Formal Namespace.
The draft application is draft-higgs-hbbtv-urn-00,    http://www.ietf.org/id/draft-higgs-hbbtv-urn-00.txt

Thanks in advance

[Ericsson]<http://www.ericsson.com/>

PAUL HIGGS
Technical Solutions Manager
Ericsson Inc

Ericsson
6 Concourse Parkway, suite 400
Atlanta, GA 30075, United States of America
Phone +1 (650) 580-1731
[email-masked]
www.ericsson.com

[http://www.ericsson.com/current_campaign]<http://www.ericsson.com/current_campaign>

Legal entity: Ericsson AB, registered office in Kista, Sweden. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 2 Sep 2014 09:39:21 -0700

Hi Paul,

I took a quick look at this, and there is one potential concern.  The draft
currently says:

Declaration of structure:

      URNs assigned by HbbTV will have the following structure based on
      the organizational structure of the resources specified in the
      HbbTV specifications:

         urn:hbbtv:<NSS>

      where the syntax of "<NSS>" is specified in Section 2.2 of the
      URN Syntax requirements ([RFC2141]).

First, this is slightly oddly stated, since it would be much clearer to say
that the NSS is 1*<URN chars>; second, this implies but does not state that
the URN is not structured within the namespace.  There certainly are
unstructured URNs, but the examples you give look very structured:

      urn:hbbtv:dash:profile:isoff-live:2012
      urn:hbbtv:sync:timeline:ebu-tt-d
      urn:hbbtv:config:oitf:oitfCapabilities:2014-1

Perhaps you would prefer to simply state that first order structure is an
hbbtv application as set out in TS 102 796 and that subsequent elements
relate to the application?

As an aside unrelated to the URN NID matters, when reviewing the ETSI
documentation, I was quite concerned to note the following:

11.2 TLS and SSL Root Certificates
A list of root certificates is maintained at
http://www.hbbtv.or/spec/certificates.html. The policy by which this list
has been derived is outlined in annex D. Terminals shall trust all root
certificates identified as mandatory and may support those certificates
identified as optional on that list, subject to the conditions in this
clause. Terminals should not trust any other root certificates.

NOTE: Including root certificates that are not on the list increases the
risk of a man in the middle attack if those root certificates have not been
audited to a similar or greater level than those on the list.

This mechanism of proposing a set of root certificates is dangerous:
first, the site at which the list is maintained is not itself protected by
TLS; second, devices which are implementing this specification in concert
with other applications will end up with the union of this list and their
own internal lists.  This increases, rather than decreases, the risk.

regards,

Ted Hardie

On Tue, Sep 2, 2014 at 5:08 AM, Paul Higgs <[email-masked]> wrote:

>  Hello
>
>
>
> In accordance with the instructions RFC 3406, the HbbTV Association kindly
> requests IETF to approve the assignment of “hbbtv” as a Formal Namespace.
>
> The draft application is draft-higgs-hbbtv-urn-00,
> http://www.ietf.org/id/draft-higgs-hbbtv-urn-00.txt
>
>
>
> Thanks in advance
>
>
>
>  <http://www.ericsson.com/>
>
>  *PAUL HIGGS *
> *Ericsson*
> <http://www.ericsson.com/current_campaign>
>
>
>
> Legal entity: Ericsson AB, registered office in Kista, Sweden. This
> Communication is Confidential. We only send and receive email on the basis
> of the terms set out at www.ericsson.com/email_disclaimer
>
>
>

---

From: Paul Higgs <[email-masked]>
Date: Tue, 2 Sep 2014 17:37:20 +0000

Hi Ted

Thanks for your review of the URN application.
The approach taken in specifying the structure of the URN, and how HbbTV will use the NSS is in line with other applications from other standardization/specification groups. By referring to RFC2141 we are essentially saying “the use will follow the same character set used by all URNs”.
Writing

         urn:hbbtv:<NSS>

      where the syntax of "<NSS>" is 1*<URN chars>.

Would mean that we end up copy/pasting all of the notation in 2.2 of [RFC2141] into this new RFC (standardization groups prefer direct referencing to copy/pasting unless there are adaptations being made)

To the aside, I can ensure your comment are raised within the HbbTV technical committee. On the first aspect, this is only a list of certificates (which are known names anyway) and not any actual certificates, so it was not deemed necessary to use TLS. On the second aspect, additional consideration will be needed, but should have no impact on the registration of a URN.

Paul

From: Ted Hardie [mailto:[email-masked]]
Sent: Tuesday, September 02, 2014 12:39 PM
To: Paul Higgs
Cc: [email-masked]; Jon Piesing; [email-masked]; Barry Leiba <[email-masked]> ([email-masked])
Subject: Re: URN request for HbbTV

Hi Paul,

I took a quick look at this, and there is one potential concern.  The draft currently says:

      HbbTV specifications:

         urn:hbbtv:<NSS>

      URN Syntax requirements ([RFC2141]).
First, this is slightly oddly stated, since it would be much clearer to say that the NSS is 1*<URN chars>; second, this implies but does not state that the URN is not structured within the namespace.  There certainly are unstructured URNs, but the examples you give look very structured:

      urn:hbbtv:config:oitf:oitfCapabilities:2014-1
Perhaps you would prefer to simply state that first order structure is an hbbtv application as set out in TS 102 796 and that subsequent elements relate to the application?
As an aside unrelated to the URN NID matters, when reviewing the ETSI documentation, I was quite concerned to note the following:
11.2 TLS and SSL Root Certificates
A list of root certificates is maintained at http://www.hbbtv.or/spec/certificates.html. The policy by which this list has been derived is outlined in annex D. Terminals shall trust all root certificates identified as mandatory and may support those certificates identified as optional on that list, subject to the conditions in this clause. Terminals should not trust any other root certificates.

NOTE: Including root certificates that are not on the list increases the risk of a man in the middle attack if those root certificates have not been audited to a similar or greater level than those on the list.

This mechanism of proposing a set of root certificates is dangerous:  first, the site at which the list is maintained is not itself protected by TLS; second, devices which are implementing this specification in concert with other applications will end up with the union of this list and their own internal lists.  This increases, rather than decreases, the risk.
regards,
Ted Hardie

On Tue, Sep 2, 2014 at 5:08 AM, Paul Higgs <[email-masked]<mailto:[email-masked]>> wrote:
Hello

In accordance with the instructions RFC 3406, the HbbTV Association kindly requests IETF to approve the assignment of “hbbtv” as a Formal Namespace.
The draft application is draft-higgs-hbbtv-urn-00,    http://www.ietf.org/id/draft-higgs-hbbtv-urn-00.txt

Thanks in advance

Ericsson
6 Concourse Parkway, suite 400
Atlanta, GA 30075, United States of America
Phone +1 (650) 580-1731<tel:%2B1%20%28650%29%20580-1731>
[email-masked]<mailto:[email-masked]>
www.ericsson.com<http://www.ericsson.com>

---

From: Jon Piesing <[email-masked]>
Date: Thu, 4 Sep 2014 08:47:27 +0000

Dear Ted, Paul, all,

Regarding the potential concern about the structure of the URN, Paul's answer is correct. We prefer to refer to other organisation's work rather than copying their work into another document or inventing a different solution. This form of structure declaration has also been used by other organisations who recently registered a URN.

Regarding the aside, we agree 100% about the concern about a union of lists. We spent quite some time discussing the risks inherent in this. We believe it is addressed by language in the quoted paragraph;

"Terminals should not trust any other root certificates. "

The HbbTV specification requires a browser to support custom objects and JavaScript APIs. These objects and APIs are not meaningful to support in other applications. As a result devices either;
i) use a different browser for the HbbTV application than for other applications (e.g. basic web browsing and SmartTV functions) or
ii) use a different configuration of the same browser
Both approaches enable complying with the "should not" and avoiding the "union of lists"  issue.

We did carefully consider if the "should not" would be better as a "shall not" but (paraphrasing RFC2119) people were able to find valid reasons in particular circumstances when including other root certificates was acceptable or even useful.

Regards

Jon Piesing
Chair HbbTV Specification Working Group and vice-Chair HbbTV Association
________________________________
From: Paul Higgs [[email-masked]]
Sent: 02 September 2014 19:37
To: Ted Hardie
Cc: [email-masked]; Jon Piesing; [email-masked]; Barry Leiba <[email-masked]> ([email-masked])
Subject: RE: URN request for HbbTV

Hi Ted

         urn:hbbtv:<NSS>

Paul

Hi Paul,

      HbbTV specifications:

         urn:hbbtv:<NSS>

Thanks in advance

Ericsson