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

[Michael Richardson <[e-mail]>]

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.

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

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

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