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

[Thomas Fossati <[e-mail]>]

> On 03/04/2022, 21:01, "Michael Richardson" <[e-mail]> wrote:
> Thomas Fossati <[e-mail]> wrote:
>     >> 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.
>
> Okay, I understand this.
> I wonder if this is significant enough a feature that it justifies the
> complexity in the client.

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.

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

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.

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

+1

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

Cheers



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.