Re: [TLS] PSK in 1.3?

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Sun, 19 October 2014 12:33 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
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 E3F751A0164 for <tls@ietfa.amsl.com>; Sun, 19 Oct 2014 05:33:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 hDkl0GiStUQJ for <tls@ietfa.amsl.com>; Sun, 19 Oct 2014 05:33:16 -0700 (PDT)
Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9651A015B for <tls@ietf.org>; Sun, 19 Oct 2014 05:33:15 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 4633E3FC8; Sun, 19 Oct 2014 15:33:12 +0300 (EEST)
Date: Sun, 19 Oct 2014 15:33:12 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20141019123312.GA13591@LK-Perkele-VII>
References: <544384C7.9030002@polarssl.org> <CABcZeBNdCiK4N7MTYD6guuyAgh7j4xVLXjpid1knjDf5yCS3JQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABcZeBNdCiK4N7MTYD6guuyAgh7j4xVLXjpid1knjDf5yCS3JQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BrZXl4u1oZJD9aCz-Blifl_Pfro
Cc: Manuel Pégourié-Gonnard <mpg@polarssl.org>, "<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 12:33:19 -0000

On Sun, Oct 19, 2014 at 12:44:16PM +0100, Eric Rescorla wrote:
>
> On Sun, Oct 19, 2014 at 10:30 AM, Manuel Pégourié-Gonnard <mpg@polarssl.org>
> wrote:
> 
> > Hi,
> >
> > Sorry if this was discussed previously and I missed it, but I was wondering
> > about the fate of PSK in TLS 1.3. The RSA and (EC)DH key exchanges were
> > removed
> > because they do not offer forward security. PSK does not offer FS either.
> > OTOH,
> > it has very interesting performance properties, namely it's the only key
> > exchange that does not require asymmetric crypto.
>
> Thanks for the reminder.
> 
> I've been assuming we would keep it and trying to bear it in mind as I think
> about design, but it's good to see this stated explicitly.

Some notes about PSK in TLS 1.2:

- TLS 1.2 has PSK identity hints. These are fundamentially 2RTT if used.
- PSK without identity hints is still 2RTT in TLS 1.2, but is not fundamentally
  2RTT (send identity in ClientHello).
- TLS 1.2 PSK requires application protocol to specify use of identity
  hints for those to be usable. At least one RFC does so, and another
  punts it forward (there are too many references to that RFC to scan
  quickly).
- There is also DHE-PSK in TLS 1.2. There kex data is combination of PSK
  kex data and anonDH kex data. This one is PFS.
- Then there is RSA-PSK in TLS 1.2. Too difficult to support and
  pretty much useless.
- 1RTT PSK also has some interactions with formulation of THS fix.
  Basically, one wants to force ServerHello to be always hashed.


-Ilari