Re: [TLS] PSK in 1.3?

Manuel Pégourié-Gonnard <mpg@polarssl.org> Sun, 19 October 2014 13:39 UTC

Return-Path: <mpg@polarssl.org>
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 828F91A0197 for <tls@ietfa.amsl.com>; Sun, 19 Oct 2014 06:39:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level:
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
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 L_5BJa1SYSd3 for <tls@ietfa.amsl.com>; Sun, 19 Oct 2014 06:39:32 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A839D1A020A for <tls@ietf.org>; Sun, 19 Oct 2014 06:39:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=6c5pZww1WnsxS4BE40vEU6pxF5UOz+Hejw0vv791NqM=; b=nQtAM+ZoR4zm/C50LROsgjZb6R8471sQdHsp6f8c9NkP2v6+zqNTfdZ8MzGqYs3E1OfgalZREJ7h+E2RfaPppoS4ymBE/74EfCstTxFUX2mje1oboxLhQsXoKow5GJQkkKzGrNvzDeUH0U9JL7/35zZxwYIOgMDjdj7i8Jug/jQ=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1Xfqhh-0001zx-Vh; Sun, 19 Oct 2014 15:39:26 +0200
Message-ID: <5443BF11.3090505@polarssl.org>
Date: Sun, 19 Oct 2014 15:39:29 +0200
From: Manuel Pégourié-Gonnard <mpg@polarssl.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Yoav Nir <ynir.ietf@gmail.com>
References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com>
In-Reply-To: <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IXPtWqU_tcKyW6ehaqhwA1DnGsk
Cc: "<tls@ietf.org>" <tls@ietf.org>
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: Sun, 19 Oct 2014 13:39:33 -0000

On 19/10/2014 15:03, Yoav Nir wrote:
> I don’t see what the rationale can be to allow non-PFS for PSK
> authentication, but prohibit it for certificate authentication.  That would
> imply that we can make a blanket statement that the data passed in
> PSK-authenticated sessions is inherently low-value or non-private.  I don’t
> think we can make that statement.
> 
I think the point is that a non-FS PSK key exchange is orders of magnitude
cheaper in terms of computation time/power usage, RAM usage, and ROM footprint
which makes it a practical option in much more scenarios than the FS variants.

For non-PSK key exchanges however, there is some asymetric crypto going on
regardless of whether the exchange is FS or not. So while the non-FS version
might be cheaper, the cost difference is nowhere near as big as ECDHE-PSK vs PSK.

Also, while it would of course be simpler to be able to state that "TLS 1.3
offers FS" rather than "TLS 1.3 offers FS *except* for PSK", it should be noted
that there is almost no risk for PSK to be negotiated "by mistake" since the
keys need to be provisioned.

Manuel.