Subject: Re: [core] [Uta] comments on draft-ietf-uta-tls13-iot-profile-04:

From: Thomas Fossati <[email-masked]>
Date: Fri, 1 Apr 2022 18:17:47 +0000

Hi Michael,

Thanks a lot for the great input.

> Michael Richardson <[email-masked]> wrote:
>
> 1) I feel that the 4.25 Too Early allocation for CoAP could use a bit
>    more explanation, and probably there needs to be some more clear
>    review at CORE.  (maybe it already happened and I missed it?)

I sent an email to CoRE [1] a while ago to try and get some informed
reviews but no one replied.  I will re-send.

[1] https://mailarchive.ietf.org/arch/msg/core/Dair8lAqEZ1h8xU6jsz053aqcOg/

>    Reading through the lines, it appears that a server that can't
>    handle early data needs to send an error code.  But such a server
>    probably doesn't know about the error code.

The option is marked critical so if the server does not understand, it
will reject with 4.02.  If it understands it and does not want to serve
the resource (say, because there is some associated state change) it
will reject with 4.25 (or whatever number IANA will assign to this
response code).  In either cases, the client will not repeat an "early
data" request for that resource.

>    I would have thought it should just hang on to the data until the
>    (D)TLS negotiation is complete.

That's an implementation choice.

>    I'm also concerned that this requires too much cross-layer
>    communication between DTLS layer and CoAP layer.

It doesn't seem the case to me: the indication is carried within the CoAP
request so it just flows end to end from an application endpoint to the
other.  But maybe I am missing something.  Can you unpack your
concern a bit more?

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

Noted [2]

[2] https://github.com/thomas-fossati/draft-tls13-iot/issues/20

> 3) While section 10 on SNI does not say *how* to use DoH or DPRIVE to
>    provide for confidentiality of names that are looked up, a naive
>    use of DoH with Google/Cloudflare/etc. by IoT devices would be a
>    problem for almost all enterprises that wish to filter the DNS used
>    by IoT devices, and to use DNS canaries to identify malware.
>
> Given that such an involved discussion is not in scope for this
> document, it might be better just to refer to the ADD WG without
> mentioning specific solutions.
> I am, in general, not convinced that encrypted SNI serves any purpose
> for most IoT devices.

Noted [3]

[3] https://github.com/thomas-fossati/draft-tls13-iot/issues/21

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

Section 15 is an attempt to clean up the cert profile we did in RFC7925.
IIRC, John Mattsson asked for this because 7925 was a bit rough around
the corners and there were a bunch of things that needed clarification.

> Validation of client certificates (whether factory provisioned
> IDevIDs, or locally enrolled LDevIDs) is a topic that I care a lot
> about, and this text is inadequate.
>
> As the (industrial) IoT market embraces IDevID certificates, there is
> some concern that different markets will put different requirements on
> IDevID contents.  So far it does not appear that anyone has created a
> situation where a single (fat) IDevID certificate couldn't be used in
> a variety of market verticals, the concern remains.
>
> It was my intention to introduce a document about this issue. I think
> that it's something that only the IETF can do.  Perhaps that would fit
> into this UTA document, or perhaps parts of this section 15 goes into
> another document.

This looks to me like it'd be a great addition to this document.
I've opened [4]; we can discuss about scope there if you want.

Cheers, thanks again!

[4] https://github.com/thomas-fossati/draft-tls13-iot/issues/22

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 03 Apr 2022 16:01:32 -0400

> data" request for that resource.

Okay, I understand this.
I wonder if this is significant enough a feature that it justifies the
complexity in the client.

    > other.  But maybe I am missing something.  Can you unpack your

The DTLS layer has to pass the early data up to the CoAP layer so that it can
reject with 4.02.
If it can do that, then it can probably just be coded to process early data.
In my server side, the DTLS layer is buried down in openssl C code, while the
CoAP layer is in ruby.

    > I've opened [4]; we can discuss about scope there if you want.

I'm concerned about slowing your document down too much, but perhaps the
timing is okay, and it might also help in getting external to the IETF review
of this profile.

When/if we are ready, I think that DANCE should be asked to review.

but, yes, let's discuss more.
I'll try to send some proposed text in the next two weeks.
Even if it doesn't go into this document, then it might form the basis of
another document.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 4 Apr 2022 10:02:30 +0000

> On 03/04/2022, 21:01, "Michael Richardson" <[email-masked]> wrote:
>     >> handle early data needs to send an error code.  But such a
>     >> server probably doesn't know about the error code.
>
>     > The option is marked critical so if the server does not
>     > understand, it will reject with 4.02.  If it understands it and
>     > does not want to serve the resource (say, because there is some
>     > associated state change) it will reject with 4.25 (or whatever
>     > number IANA will assign to this response code).  In either
>     > cases, the client will not repeat an "early data" request for
>     > that resource.
>
> Okay, I understand this.

This is a good question, which at the end of the day is for CoRE to
decide.  RFC8446 says "Application protocols MUST NOT use 0-RTT data
without a profile that defines its use." so this is a gap that we are
trying to bridge for CoAP here, based on existing experience with HTTP.
If the CoRE community doesn't feel this feature is relevant, or they
want to punt for now to gather more experience, it's totally fine.  We
could drop Section 14 and possibly resume it later in a separate doc.  I
suspect the fact that DTLS 1.3 has not been published yet may be a
reason for things moving slower than anticipated in this area.

>     > It doesn't seem the case to me: the indication is carried within
>     > the CoAP request so it just flows end to end from an application
>     > endpoint to the other.  But maybe I am missing something.  Can
>     > you unpack your concern a bit more?
>
> The DTLS layer has to pass the early data up to the CoAP layer so that
> it can reject with 4.02.
> In my server side, the DTLS layer is buried down in openssl C code,
> while the CoAP layer is in ruby.

The thing is that this feature is enabled on a per-resource basis, so it
needs to bubble up.  It can't be handled transparently by the lower bits
of the stack.

>     >> IDevIDs, or locally enrolled LDevIDs) is a topic that I care a
>     >> lot about, and this text is inadequate.
>     >>
>     >> As the (industrial) IoT market embraces IDevID certificates,
>     >> there is some concern that different markets will put different
>     >> requirements on IDevID contents.  So far it does not appear
>     >> that anyone has created a situation where a single (fat) IDevID
>     >> certificate couldn't be used in a variety of market verticals,
>     >> the concern remains.
>     >>
>     >> It was my intention to introduce a document about this issue. I
>     >> think that it's something that only the IETF can do.  Perhaps
>     >> that would fit into this UTA document, or perhaps parts of this
>     >> section 15 goes into another document.
>
> I'm concerned about slowing your document down too much, but perhaps
> the timing is okay, and it might also help in getting external to the
> IETF review of this profile.
>
> Even if it doesn't go into this document, then it might form the basis
> of another document.

+1

Let's give it a try, if it explodes we still have a fall back.

Cheers

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 4 Apr 2022 11:22:33 +0000

Dear CoRE folks,

I wanted to hear your thoughts about the 0-RTT extensions for CoAP
described in draft-ietf-uta-tls13-iot-profile [0].

I tried this before [1], but it looks like there was no interest then, and I
wonder whether the situation has changed in the meantime?

Copied below an extract of the relevant piece of the conversation with
Michael to give you a bit more context about where this email comes from.

Cheers & thanks in advance for your time.

[0] https://www.ietf.org/archive/id/draft-ietf-uta-tls13-iot-profile-04.html#name-0-rtt-data
[1] https://mailarchive.ietf.org/arch/msg/core/Dair8lAqEZ1h8xU6jsz053aqcOg/

> From: Iotops <[email-masked]> on behalf of Thomas Fossati <[email-masked]>
> Date: Monday, 4 April 2022 at 11:03
> To: Michael Richardson <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, Hannes Tschofenig <[email-masked]>
> Subject: Re: [Iotops] [Uta] comments on draft-ietf-uta-tls13-iot-profile-04:
> >     >> Reading through the lines, it appears that a server that
> >     >> can't handle early data needs to send an error code.  But
> >     >> such a server probably doesn't know about the error code.
> >
> >     > understand, it will reject with 4.02.  If it understands it
> >     > and does not want to serve the resource (say, because there is
> >     > some associated state change) it will reject with 4.25 (or
> >     > whatever number IANA will assign to this response code).  In
> >     > either cases, the client will not repeat an "early data"
> >     > request for that resource.
> >
> > Okay, I understand this.
> > I wonder if this is significant enough a feature that it justifies
> > the complexity in the client.
>
> trying to bridge for CoAP here, based on existing experience with
> HTTP.  If the CoRE community doesn't feel this feature is relevant, or
> they want to punt for now to gather more experience, it's totally
> fine.  We could drop Section 14 and possibly resume it later in a
> separate doc.  I suspect the fact that DTLS 1.3 has not been published
> yet may be a reason for things moving slower than anticipated in this
> area.
>
> >     > It doesn't seem the case to me: the indication is carried
> >     > within the CoAP request so it just flows end to end from an
> >     > application endpoint to the other.  But maybe I am missing
> >     > something.  Can you unpack your concern a bit more?
> >
> > The DTLS layer has to pass the early data up to the CoAP layer so
> > that it can reject with 4.02.
> The thing is that this feature is enabled on a per-resource basis, so
> it needs to bubble up.  It can't be handled transparently by the lower
> bits of the stack.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 5 Apr 2022 13:13:56 +0000

Hi Michael,

Thanks for your review.

Let me provide you my remarks below.

-----Original Message-----
From: Michael Richardson <[email-masked]>
Sent: Saturday, March 26, 2022 1:42 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: Hannes Tschofenig <[email-masked]>
Subject: comments on draft-ietf-uta-tls13-iot-profile-04:

I read draft-ietf-uta-tls13-iot-profile-04 today.
Thank you Hannes for presenting it at IOTOPS.  To be, it is precisely this kind of thing that IOTOPS was created for.

1) I feel that the 4.25 Too Early allocation for CoAP could use a bit more
   explanation, and probably there needs to be some more clear review at CORE.
   (maybe it already happened and I missed it?)
   Reading through the lines, it appears that a server that can't handle
   early data needs to send an error code.  But such a server probably
   doesn't know about the error code.  I would have thought it should just
   hang on to the data until the (D)TLS negotiation is complete.
   I'm also concerned that this requires too much cross-layer communication
   between DTLS layer and CoAP layer.

[hannes] With the design we are following the corresponding design of HTTP. Thomas has sent a mail already to solicit feedback.

2) A long thread at LAMPS two years suggests that the term "Intermediate CA"
   applies only to cross-certification authoritiy bridges, and the term
   "Subordinate CA" should be used.  That this is consistent with history
   going back to RFC4949.

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

3) While section 10 on SNI does not say *how* to use DoH or DPRIVE to provide
   for confidentiality of names that are looked up, a naive use of DoH with
   Google/Cloudflare/etc. by IoT devices would be a problem for almost all
   enterprises that wish to filter the DNS used by IoT devices, and to use
   DNS canaries to identify malware.

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

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

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

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

Validation of client certificates (whether factory provisioned IDevIDs, or locally enrolled LDevIDs) is a topic that I care a lot about, and this text is inadequate.

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

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

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

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

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Mon, 11 Apr 2022 13:18:29 -0400

Hannes Tschofenig <[email-masked]> 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   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [