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

From: Peter Gutmann <[email-masked]>
Date: Thu, 22 Jan 2015 22:07:52 +0000

Aaron Zauner <[email-masked]> 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.

---

From: Aaron Zauner <[email-masked]>
Date: Sat, 24 Jan 2015 20:31:19 +0100

Hi Peter,

> doubt that ever gets used.

Thanks for your commentary and insight. I find this (personally) very
interesting. As I've pointed out in private correspondence: all the PSK
ciphersuites will stay in the document unchanged. Due to good points
being raised during the discussion for them not to be removed.

> lifetime at system build time, but that's just going through the motions of

That's a nice trick but as you point out pretty useless in terms of a
PKI. Although I'm pretty sure some vendors will ship uniform client
certificates on devices; that /really/ should not be recommended anywhere :)

I've still gotten no feedback if SRP will still be supported with TLS
1.3. I really think SRP is a valuable protocol but rarely used. I have
not included SRP ciphersuites in my ID so far.

Aaron

---

From: "Jack Lloyd" <[email-masked]>
Date: Sun, 25 Jan 2015 09:27:24 -0500

> not included SRP ciphersuites in my ID so far.

I believe SRP is, like PSK, useful in protocols outside of IETF scope and
would love for there to be an SRP ciphersuite option that wasn't AES/CBC.

Cheers,
  Jack