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

[Thomas Fossati <[e-mail]>]

Hi Michael,

Thanks a lot for the great input.

> Michael Richardson <[e-mail]> 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.