[Uta] Re: draft-ietf-uta-tls13-iot-profile-21 ietf last call Artart review

[Michael Richardson <[e-mail]>]

Your review is captured at:
  https://github.com/thomas-fossati/draft-tls13-iot/issues/182

with sub-issues as per below.
Thank you for your direct and specific suggestions.

Martin Thomson via Datatracker <[e-mail]> wrote:
    > Let me preface this review with a confession.  I tend to think that
    > profiling work is worse than a waste of time, it tends to be harmful to
    > interoperability.  If we believe that there is value in having IoT
    > devices use the same protocols as everyone else, then they should use
    > the same protocols.  The problem with profiles is that you lose
    > interoperability once you step outside of the profile.

Fine, then why is there a TLS MTI that excludes AES_128_CCM_8? :-)
THAT'S A PROFILE.  TLS has already got a profile, and it wastes huge amount of
energy because that's not the cipher that went into hardware some time ago.
So, that's still listed, and it's MUST-... saying.. please plan to stop.
Software/firmware does get revised even when hardware is not replaced.
(I have a supplier of 3-year-ago EOL hardware that released new firmware
with a very recent openssl 3.x... on a Linux 4.9 kernel)

Anyway, this document ALSO suggests AES_128_GCM_SHA256 is important,
and by writing that down, we significantly improve the likelyhood that a next
generation of power-efficient hardware will support it.  This is already
happening, but without a statement like this, some CFO will complain about
using the $2.50 part rather than the $1.95 part.

So, that overlaps with 8446 MTI, right?   Five years ago, this would not have
been possible to specify.

Beyond CCM vs GCM, what parts of the profile are not proper subsets of what's
out there?

A significant part of the document says thing about certificates, CAs,
revocation , etc..  and this is a UTA document.

    > I'll freely admit that if your strategy depends on incumbent
    > implementations all making concessions to the needs of your new thing,
    > you don't have a great path to success.

Mostly, this document doesn't care about browsers.
It's about device to device and device to cloud.
{This is not the SETTLE problem}

If the 10,000 energy harvesting pipeline flow meters (with CCM_8 in
hardware) need to talk (D)TLS to a collector, and that requires hardware TLS
termination, then this document is what you'd cite when you acquire that
terminator.
Without this document... likely they will deploy TLS 1.1. Seriously.
(I won't go on, as there is a code of conduct)

    > # Overall

    > This document is a bit of a mixed bag.  It's well written and generally
    > quite clear.  However, it lacks coherency.  If this were a -02 of a

Yes, your point is well taken.
It got patched too many times over too long a time... because it has
progressed too slowly to remain in our L2 cache.
I am not certain I've captured your review comments into the right issues.

    > # Substantial Comments

    > In Section 1, This is highly misleading:

    >> [RFC4279] introduced PSK-based authentication to TLS, a feature
    >> re-designed
    > in TLS 1.3. The "PSK identity hint" defined in [RFC4279], which is used
    > by the server to help the client in selecting which PSK identity to
    > use, is, however, not available anymore in TLS 1.3.

    > The pre_shared_key extension in TLS 1.3 fulfills an identical function,
    > but this fails to mention that.  It implies that you can't use PSK
    > identity hints, which is simply untrue.

https://github.com/thomas-fossati/draft-tls13-iot/issues/182

    > In Section 2, I always thought that this was silly:

    >> This document reuses the terms "SHOULD+", "SHOULD-" and "MUST-" from
    > [RFC8221].

    > It's even more silly when you realize that these are used in exactly
    > one place, where a the existing explanation in Section 20
    > ("TLS_AES_128_CCM_8_SHA256 is weak and we are likely to stop mandating
    > it in future profiles in favor of TLS_AES_128_CCM and
    > TLS_AES_128_GCM_SHA256") is already sufficient.  FWIW, that statement
    > is an exemplar of the problem I have with profiling generally.

I don't know what to say here.  IPsec WG has found it very useful.
Feedback from industry people over 25 years has been very positive.
https://github.com/thomas-fossati/draft-tls13-iot/issues/184

    > In Section 3, this:

    >> PSK with (EC)DHE is optional and not assumed by default.

    > ...is especially rich after the near-rant in the introduction about the
    > post-compromise security of the key update mechanism in TLS.  And
    > Section 7.  The idea that you might not refresh keying material seems
    > inconsistent with that thinking.  Even being neutral (leaving the point
    > of whether to perform a fresh key exchange during the handshake
    > unstated) would be preferable to what amounts to saying that you don't
    > rekey when you have a PSK.

https://github.com/thomas-fossati/draft-tls13-iot/issues/185

    > In Section 3, restating extension requirements from Section 9.2 of RFC
    > 8446 for "plain" PSK is problematic.  TLS 1.3 also mandates the
    > supported_groups and key_share extensions; is that suddenly not
    > required?  ALPN is not mandated in TLS 1.3, but it is here, without
    > context.  Finally, from an editorial perspective, this really isn't the
    > right place for many of these requirements.  A section, like what is in
    > TLS, that summarizes mandatory extensions, with reference to the
    > sections that establish reasons, is useful.  This section need only
    > restate how this profile differs from TLS 1.3 with respect to
    > connection establishment with PSK-only authentication.  The ALPN point
    > deserves its own section, as it has no relationship to "plain" PSK
    > authentication (it also applies if certificates are used).

https://github.com/thomas-fossati/draft-tls13-iot/issues/186

    > Sections 4 through 6 are not really helpful.  These are a statements of
    > fact that don't lead to any particular recommendation or
    > interoperability requirement.  They could be dropped.

https://github.com/thomas-fossati/draft-tls13-iot/issues/187

    > Does Section 8 need a reference to RFC 6919 for this?  "Implementations
    > may not support these suites" I don't see what value this statement
    > provides.  In my view, this section should be dropped.  The intended
    > status here is PS, RFC 9150 is Informational (and a bad idea, see my
    > introductory rant).

https://github.com/thomas-fossati/draft-tls13-iot/issues/188

    > I'm not confident that the claims about congestion collapse and ACKs in
    > Section 10 holds. ACKs improve efficiency, sure, but claims about them
    > helping with congestion collapse seem overblown.  The recommendations
    > here are otherwise good.

I'm unclear if there something we need to change.

    > The discussion on ECH in Section 12 would be best left out.  It's a
    > progressive enhancement that - as noted - is unlikely to be adopted in
    > many IoT deployments, so why waste the bytes on explaining this.  The
    > ECH spec does a better job of explaining its own applicability and
    > constraints on use.

https://github.com/thomas-fossati/draft-tls13-iot/issues/189
I think that the reason to say it here is so when the OT people are arguing
with the IT people about SNI inspection, it's in a document they already have.

    > The equivocating on SNI in Section 12 is challenging for me.  Making it
    > MTI is fine, but totally redundant, given that TL 1.3 does that.  All
    > that text does is make the reader uncomfortably aware of the internal
    > deliberations of the group that produced this spec.

https://github.com/thomas-fossati/draft-tls13-iot/issues/196
Perhaps we can adjust the wording to make people less uncomfortable.
There are strong suggestions out there that SNI is mandatory, and
certainly I think any browser that did not support it would be useless.

    > However, the main challenge with the SNI text is this whole business
    > recommending that the SNI be ignored.  That's not a good plan.

For device to device, the way in which the client specify the server is
at best, wrong.   They do *not* do DNS-ID.  So it is extremely unlikely, in
the device to device situation, that the SNI is correct.
That's why I argue to it in by default, because (a) client libraries need it
compiled in, as (b) it's critical in device to cloud.
Whatever the operator/configurator/discovery protocol used, put that in.

    > A
    > device that acts as a server is in four states: 1. It has no name and
    > it positively knows this.  In this case, SNI should be absent and
    > appearance of SNI is probably grounds for a rejecting a
    > connection.

The server usually has no idea idea if it has a name, or even what that name is.
Could be NAT64, provider domains, mDNS, DNS-SD, IPv4 Link-Local...

    > 2. It has a name, but it doesn't know what it is.  This is
    > often the case when you have a device that is deployed without full
    > knowledge of how others might discover it.  In this case, the device
    > can ignore SNI as suggested.

This is exactly the typical case.
Anything else requires knowledge/configuration which is just not available in
the field.

    > 3. It has a single name and knows it.  In
    > this case, SNI should be present and set to that name.  An incorrect
    > SNI is grounds for rejecting connections.  The decision in this case
    > about what to do when SNI is absent is open to choice.  Like in the
    > multi-name case, it is very reasonable to reject connection attempts
    > when there is no SNI, but, unlike the multi-name case, it would also be
    > OK to accept those connections.

    > 4. It has multiple names.  This is
    > where SNI is necessary.  Having no SNI or an unknown SNI should result
    > in connections being rejected.  As noted, this is an unusual condition
    > for an IoT device, but it's a valid state.

The behaviour of rejecting wrong SNI will have OT people turn TLS off.
We added SNI to deal with IPv4 run-out vs virtual hosting, right?

    > Section 16 seems to assume that this document is about CoAP.  This
    > section probably should be rewritten to be more generic.

https://github.com/thomas-fossati/draft-tls13-iot/issues/190

    > I did not read Section 17 closely.  It's certainly very long relative
    > to other sections.  It seems to me like this section is a completely
    > separate document.  Certificates and PKIX requirements are not about
    > TLS, even if they are often presented in TLS.  In my mind, they are a
    > completely different thing.  I would strongly suggest a separate
    > document for all this stuff.

https://github.com/thomas-fossati/draft-tls13-iot/issues/191

    > Section 19 outlines several strategies for reducing certificate
    > overhead.  Some of these (cached-info, compression) have some
    > distinctly unfriendly characteristics when it comes to devices with
    > limited resources.  For instance, decompression can need a pretty
    > substantial amount of memory and code.  It might be worth pointing that
    > out.

    > The recommendation to use alternative certificate formats in Section 19
    > doesn't really contribute to interoperability.  In the extreme, it
    > risks making things worse.  If the alternative format is necessary to
    > fit within implementation constraints on a device, that device will be
    > unable to talk to any other implementation that can't use that format.

https://github.com/thomas-fossati/draft-tls13-iot/issues/192

    > The uncertainty about sending pinned certificates here is in a list
    > that is introduced as being about trust anchors.  I guess that a pinned
    > certificate is a form of trust anchor, but that's not generally how it
    > is thought about.  (This is a case where cached-info makes a ton of
    > sense, by the way.  Missed opportunity.)

https://github.com/thomas-fossati/draft-tls13-iot/issues/193

    > The paragraph that recommends the use of the Trusted CA Indication
    > extension seems like a spectacularly bad idea to me.  Not because it
    > can't work, but because it's not widely implemented and deployed.

https://github.com/thomas-fossati/draft-tls13-iot/issues/194

    > All of Section 19 really just contributes to an overwhelming impression
    > of a lot of spaghetti being flung at different walls.  There's a lot of
    > "try this", but not a lot of profiling and certainly not a lot of
    > interoperability.  I know that authentication is THE unsolved part of
    > any deployment that uses TLS outside of the web (where we have the
    > luxury of a common PKI), but this section hasn't really contribute to
    > better interoperability.

I will leave this in the parent issue.

    > I know that Russ already pointed out deficiencies in Section 22.  I
    > want to support that position.  We know how to deal with HNDL attacks
    > and those defenses are already deployed (and advancing toward RFC
    > publication on the standards track, after a lot of delay and needless
    > churn).  You can at a minimum mandate the use of those mechanisms.

And this.

    > The size of handshakes is clearly a burden here, but the working group
    > can and should address that point.  The text might have been written at
    > a different time, but circumstances have changed and the document can't
    > duck this issue any more.

The TLS or the UTA WG?

    > It's OK not to deal with PQ auth yet, but be clear that this is
    > deliberate.  I don't share Russ' view of the PSK + certificate thing in
    > every respect, but in this specific context, where the authentication
    > architecture is more inchoate, it makes a lot more sense to consider
    > that approach.  It's a pretty effective stopgap, even if it doesn't
    > scale out well.

If we were to delay this another year, then we'd be able to deal with it.
It's not just the TLS KEM here, it's the rest of the authentication ecosystem
that is still, I think, too vague to specify.
I hope that another document will be started about quantum-safe authentication.

    > In Section 23, there is mention of the improved privacy for
    > certificates.  This is fine, but it misses the key caveat: server
    > identity might be encrypted, but it is encrypted toward a client that
    > has not been authenticated by the server.  So, while an observer cannot
    > know what identity was offered on an arbitrary connection to a client,
    > it is generally possible to ask for that information and receive the
    > same value, if the server provides the same identity to clients.  (ECH
    > changes this situation somewhat for the better for multi-name servers,
    > but that probably doesn't apply.  Also, ECH was pretty strongly
    > discouraged here; it's strange to see the endorsement here in light of
    > that.)

Leaving this in parent issue.

    > Section 24 should just be the first sentence.  Surely, the seemingly
    > random addition of text about root certificates can be moved to a more
    > appropriate section.

https://github.com/thomas-fossati/draft-tls13-iot/issues/195

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