[art] draft-ietf-uta-tls13-iot-profile-21 ietf last call Artart review

[Martin Thomson via Datatracker <[e-mail]>]

Document: draft-ietf-uta-tls13-iot-profile
Title: TLS/DTLS 1.3 Profiles for the Internet of Things
Reviewer: Martin Thomson
Review result: Not Ready

# On Profiling Protocols

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.

Consider this: full implementations of TLS that only implement the mandatory
cipher suite from RFC 8446 will not interoperate with implementations of this
profile that only implement the mandatory cipher suite from the profile.  In
effect, the profile risks forking the protocol.

TLS has a bunch of baggage, for sure, but it can be adapted to more scalable
for use on low end devices. I'm not talking cTLS, which I'm going to call a
boondoggle, but simple accommodations, like RFC 8449.  Now, I'll admit that the
failure there is that this requires concessions from the "big" devices to allow
for "small" devices to be full participants, but that is consequence of the
starting point in the TLS design.  That approach works toward having a single
ecosystem, rather than the fork that profiles tend to produce.

Profiles like this only serve to ensure that IoT devices don't interoperate
with everything else.  That's a significant loss.

I realize that I likely won't convince many people that this is the right plan.
 I doubt that these ideas will convince the people who are gainfully employed
in building a parallel reality of the error of their ways.  Why else do we have
a completely bespoke IoT stack that replicates many of the functions of other
protocols.  draft-montenegro-httpbis-h2ot wasn't popular back then, despite it
being the right idea.

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.  A profile is the half-way effort toward that end.  You don't
duplicate all the effort of building the stack and you at least have some hope
of having your stuff interoperate in some limited fashion.  (Hope is not a
strategy, of course.)  So, I get how we end up in this state.  I don't have to
like it.

# 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 working group
draft, I'd have said that it is showing promise, but it needs a fair bit of
work to get it finished.  At the same time, its showing its age a little, with
evidence of outdated recommendations; see the PQ discussion.

Like Russ, I think that this could use some more work.  Hopefully, my feedback
helps.

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

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.

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.

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

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.

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

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.

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.

The equivocating on SNI in Section 12 is challenging for me.  Making it MTI is
fine, but totally redundant, given that TLS 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.

However, the main challenge with the SNI text is this whole business
recommending that the SNI be ignored.  That's not a good plan.  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. 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. 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.

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

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.

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.

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

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.

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

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.

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.

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

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.