Re: [TLS] Inclusion of OCB mode in TLS 1.3

[Peter Gutmann <[e-mail]>]

Aaron Zauner <[e-mail]> writes:

>The issue I see is that confined/embedded might not have DHE as fallback in
>any case, because they probably opt to not support it because if plattform
>constraints. And as far as I understand PSK is exactly there for these use-
>cases.

Not necessarily.  When I did my PSK draft I added the discussion of embedded
systems use mostly as a red herring to deal with the people who complained
that since we already have PKI in all its infinite wonder and perfection to
secure TLS, there's no need for anything involving shared secrets.  The
mention of use in embedded systems was to deal with the PKI zombies, not
embedded systems.  RFC 4279 doesn't mention embedded systems at all.

>It would be really good to have someone doing TLS crypto in the embedded
>world comment on this topic.

I've got lots of TLS running in embedded systems.  I'm not aware of anything
currently using pure PSK, it's always DHE with PSK.  To deal with lower-power
CPUs, you use smaller DH parameters.  Even for older stuff from before it was
ARM everywhere (with a side order of MIPS, PPC, NIOS, and whatnot everywhere),
the standard approach was still to use smaller RSA/DH values rather than pure
PSK.  I support non-PFS PSK, but only after all of the PFS PSK suites, so I
doubt that ever gets used.

At a pinch you can even do DHE-RSA in an embedded device, you just memcpy()
out a pre-encoded certificate chain that's generated on install so you don't
have to have any certificate-processing code present.  Problem is that (a)
this doesn't give you mutual auth and (b) more importantly certificates
inherently don't work with embedded devices which can't be identified or
provisioned in any manner that's expected for certificates.  At best you can
hardcode in a fixed certificate with a meaningless identifier and infinite
lifetime at system build time, but that's just going through the motions of
using certs.

Peter.