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

[Achim Kraus <[e-mail]>]

Hello Martin,

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

FMPOV, that depends on what real world IoT deployments are using.
In my experience (limited to CoAP/DTLS) many follow the IoT profiles,
because of the benefits it provides in IoT for pretty small and power
constrained devices.

To cover also the cases, where devices are connecting to more general
servers (using other protocols as well), I remember, that Thomas did
an investigation at that time, checking the major cloud provider's
endpoints (e.g. CCM vs. GCM).

Therefore it may be an loss in interoperability, but for me
this is hardly a "significant" one.

br
Achim

Am 28.05.26 um 03:51 schrieb Martin Thomson via Datatracker:
> 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.
> 
> 
> _______________________________________________
> Uta mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]