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

Peter Gutmann <> Thu, 22 January 2015 22:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 561551A87E4 for <>; Thu, 22 Jan 2015 14:07:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cT4vyV7reY7J for <>; Thu, 22 Jan 2015 14:07:55 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 319451A87A5 for <>; Thu, 22 Jan 2015 14:07:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=uoa; t=1421964476; x=1453500476; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=lehG/TvYUiRZCVY1rEy6Ip0PA7IYGcXCEqF2Rozb73I=; b=ugIIr8s7Brv1bZC6b1jv4NYBkAqs7Lyy8hrSGq1uN+qf7/2aJSHRbn3v +O78hBO+q2wK5W3F+/cxgBj8ze2blDwMTqIpdfQQVde4rFXKsjoQIsFju zMzPW/t5x2eBPbjCA84Vf2xVvqmeQIbi85NWgfFVH0i6P5gyL9U4r4oA1 w=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="303155665"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 23 Jan 2015 11:07:53 +1300
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Fri, 23 Jan 2015 11:07:52 +1300
From: Peter Gutmann <>
To: "<>" <>
Thread-Topic: [TLS] Inclusion of OCB mode in TLS 1.3
Thread-Index: AdA2j92obButSWp5QhmD2iJJC2WYEQ==
Date: Thu, 22 Jan 2015 22:07:52 +0000
Message-ID: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Jan 2015 22:07:59 -0000

Aaron Zauner <> 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-

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.