Re: [TLS] PSK in 1.3?

Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 21 October 2014 08:07 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155381AD289 for <tls@ietfa.amsl.com>; Tue, 21 Oct 2014 01:07:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuoDJQsn31gr for <tls@ietfa.amsl.com>; Tue, 21 Oct 2014 01:06:57 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27341AD0C2 for <tls@ietf.org>; Tue, 21 Oct 2014 01:05:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1413878716; x=1445414716; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=+VoCBKuq9UtJ3XtYG9d0Z9eNqwJpGQ1rnI3v2BkEFqc=; b=O4k8iaOncXr6FLKPNIBV71X5PlUj5ibMT34lmZcuHBzRfIa9Ei7Q1df9 VoDWt1oK9GsloptyKlRp5yYDBsbz5afkHD6YJlaiZMxXA5jvTbryHE52c h5oET+Q9PD2GVqf0HYvBOb42yAKTkghPrr+be+VGPhI2/7xLW2LN4M81X 0=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="284700837"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Oct 2014 21:05:14 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Tue, 21 Oct 2014 21:05:13 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] PSK in 1.3?
Thread-Index: Ac/tBb3VLRb4HCJXSvm+2qnGVPmAmg==
Date: Tue, 21 Oct 2014 08:05:13 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9D471A@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FZP71-YaTiG-FuylsVZ0x-hULoQ
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Oct 2014 08:07:02 -0000

Manuel Pégourié-Gonnard <mpg@polarssl.org> writes:

>In addition to what Watson said, it's generally a bad idea to roll one's own
>crypto protocol, it's too easy to get things wrong. Even with PSK, TLS brings
>you important things: a record protocol, a way to derive session keys from the
>long-term secret key, etc.

I'm just reviewing a design right now for which there's been an argument put
forward that it's too complicated and you could roll your own protocol that
would be much simpler.  The implementers are using EAP-PSK, which is a wee bit
complex, but then it has exactly the benefits you cite, everything's well-
defined (although the lack of test vectors is annoying), you just grab the RFC
and code it up and you're done.  Sure, you could homebrew your own
application-specific protocol that's simpler, but then you'd end up with a
proprietary, non-vetted, nonstandard one-off custom job that nothing else on
earth can talk to.  That may be fine if you're building an Arduino-controlled
electronic cat-door for your home, but not if it's commercial SCADA gear
that's going to be deployed all over the world.

We'll see how the discussion over this pans out...

Peter.