Re: [Iotops] comments on draft-ietf-uta-tls13-iot-profile-04:

[Michael Richardson <[e-mail]>]

Hannes Tschofenig <[e-mail]> wrote:
    mcr> 2) A long thread at LAMPS two years suggests that the term
    mcr> "Intermediate CA" applies only to cross-certification authoritiy
    mcr> bridges, and the term "Subordinate CA" should be used.  That this
    mcr> is consistent with history going back to RFC4949.

    hannes> [hannes] We can note in the terminology section that the terms
    hannes> "Intermediate CA" and "Subordinate CA" are used interchangeably
    hannes> in this document because with regards to this document the
    hannes> distinction is not relevant.

My view is that we have confused people by using them interchangeably, and we
should stop doing that.   Why not just use subordinate CA then?
The relevance has to do with how path validation is managed.  

   mcr> Given that such an involved discussion is not in scope for this
   mcr> document, it might be better just to refer to the ADD WG without
   mcr> mentioning specific solutions.  I am, in general, not convinced
   mcr> that encrypted SNI serves any purpose for most IoT devices.

    hannes> [hannes] Major IoT service providers have cared about hiding
    hannes> client identity information by utilizing session resumption in
    hannes> TLS 1.2 to accomplish what is now available in TLS 1.3 with
    hannes> earlier encryption of handshake messages. While I personally
    hannes> haven't heard anyone asking for SNI encryption yet, I expect the
    hannes> same companies who cared about hiding the client identifiers to
    hannes> also take a look at the SNI encryption. While there are pros and
    hannes> cons of using these mechanisms, I am only suggesting to reference
    hannes> ongoing IETF work.  Companies then need to decide whether a
    hannes> specific solution matches their requirements.

Yes, what I'm saying is that just reference it.
Trying to say much more about ongoing work is a recipe for getting something
wrong and having to revise the document late in the process.

   mcr> 4) section 15 There is much discussion about what goes into the
   mcr> certificates.  I didn't really understand why that is in this
   mcr> document.  Validation of server certificates is well covered in
   mcr> RFC6125, I think.

    hannes> [hannes] In my experience, validation of server certificates has
    hannes> been a source of confusion in IoT and RFC 6125 does not talk
    hannes> about the use of IoT protocols like CoAP and MQTT. I have seen
    hannes> various companies and organizations creating their own profiles
    hannes> of RFC 6125 in the past, which has resulted in the text of this
    hannes> section.

Okay, so either we have to do much more, or we have to do much less here.

   mcr> As the (industrial) IoT market embraces IDevID certificates,
   mcr> there is some concern that different markets will put different
   mcr> requirements on IDevID contents.  So far it does not appear that
   mcr> anyone has created a situation where a single (fat) IDevID
   mcr> certificate couldn't be used in a variety of market verticals,
   mcr> the concern remains.

   mcr> It was my intention to introduce a document about this issue. I
   mcr> think that it's something that only the IETF can do.  Perhaps
   mcr> that would fit into this UTA document, or perhaps parts of this
   mcr> section 15 goes into another document.

    hannes> [hannes] This section was difficult to write because - there are
    hannes> lots of different IoT verticals, - companies often do not want to
    hannes> share information about what they do in their deployments, and -
    hannes> there are many different identifier formats.

    hannes> It would, of course, be worthwhile to ask around again to see
    hannes> what current deployments are using. I could check the public
    hannes> documentation of major IoT service providers to get this process
    hannes> started.

Thomas suggested that this was welcome in this document.
I will attempt to write some text to go here.

The TL;DR summary is: "don't shoot yourself in the foot" :-)
Or, be tolerant of things you don't understand.

I agree that it needs a road show to bring this to many other verticals, but
I think that ultimately, those other entities are looking to us to give them
something to cite.  The question is whether the TLS profile is the right
place for it.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [