Re: [TLS] PSK in 1.3?

"Dan Harkins" <dharkins@lounge.org> Mon, 20 October 2014 17:16 UTC

Return-Path: <dharkins@lounge.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 F09961A1A98 for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 10:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level:
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 kNtG_LoiDti1 for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 10:16:04 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6652B1A1B21 for <tls@ietf.org>; Mon, 20 Oct 2014 10:06:29 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id CDA2E10224008; Mon, 20 Oct 2014 10:06:28 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 20 Oct 2014 10:06:29 -0700 (PDT)
Message-ID: <74986741b83a76277b2fcfd1e74a75d4.squirrel@www.trepanning.net>
In-Reply-To: <CACsn0ck0FRHFek59A5+jxDkDGEtXPT8HejO3wO4HnYfHCw6hYg@mail.gmail.com>
References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net> <CACsn0ck0FRHFek59A5+jxDkDGEtXPT8HejO3wO4HnYfHCw6hYg@mail.gmail.com>
Date: Mon, 20 Oct 2014 10:06:29 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Watson Ladd <watsonbladd@gmail.com>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/k21jI83kZ207r00bZ7AyTIdL8mQ
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: Mon, 20 Oct 2014 17:16:06 -0000

On Mon, October 20, 2014 7:25 am, Watson Ladd wrote:
> On Mon, Oct 20, 2014 at 5:13 AM, Dan Harkins <dharkins@lounge.org> wrote:
>>
>> On Sun, October 19, 2014 7:35 am, Yoav Nir wrote:
>>>
>>> I also understand that in practice, PSK ciphersuites are used only by
>>> small devices, whereas the web and SMTP and other things never went for
>>> it. But the standards don’t say that. They don’t say that
>>> PSK
>>> ciphersuites are especially for constrained devices. So if we insist
>>> that
>>> the same TLS 1.3 be used for both, and we don’t want to say that
>>> PSK is
>>> for weak security, then we should have a good story of why PFS is not
>>> needed for PSK uses, whereas it’s essential for all RSA uses.
>>> If I
>>> understand the mechanism correctly, PSKs tend to be long-lived, and a
>>> subsequent compromise of a PSK (even if it is expired at the time of
>>> compromise) allows an attacker to decrypt the content of a TLS session.
>>
>>   The non-PFS PSK ciphersuites are no different than the widely
>> discredited, and easily cracked, WPA-PSK mode of WiFi security. It would
>> be a really bad idea to continue with these ciphersuites in TLS 1.3. But
>> the
>> issue is not just PFS (or the lack of it), it's that PSK ciphersuites
>> are
>> susceptible to dictionary attack.
>
> Good luck with that: it says preshared key, not preshared password.
> Yes, section 7 of RFC 4279 probably should be fleshed out more to deal
> with this. Yes, we should have modern PAKE suites. SPAKE2, not
> Dragonfly.

  There is nothing to flesh out because you seem to not understand
what a dictionary attack is-- but you're in company because neither
did the editors of that RFC.

  Protocols that use a static, symmetric credential like a PSK (or a
password, the difference is semantic) are all flawed because the
adversary is always assumed to have access to a pool from which
the PSK (or password is drawn. Resistance against dictionary attack
is then a demonstration that the advantage gained by the adversary
is due to _interaction_ and not _computation_.

  Merely making the pool from which the PSK is drawn, for instance
by making it a bigger or including mixed case, etc, does not make
the protocol resistant to dictionary attack. With the TLS PSK
ciphersuites the adversarial advantage always grows with
computation no matter how big, or complex, you make the PSK.

  Therefore, all of the TLS PSK ciphersuites are susceptible to
dictionary attack, notwithstanding any addition section 7 flesh
you wish to add.

>>> So either we believe that PSK compromise is unlikely, or we believe
>>> that
>>> the data in a connection with a PSK ciphersuite is not
>>> future-sensitive.
>>> If we don’t, we’re saying that we’re just piling
>>> on security
>>> nice-to-haves because we think the users can handle them.
>>
>>   There's no way that the protocol can be defined to justify that
>> belief.
>> What you're talking about is how people end up using the protocol and
>> that is entirely out of the power of this WG. What we can do is to make
>> TLS be as _misuse resistant_ as possible. And to do that we should not
>> allow PSKs in TLS 1.3 unless they are used in a PAKE.
>>
>>   By the way, I'm surprised that no one is expressing outrageous outrage
>> at the lack of a security proof for PSK ciphersuites.
>
> What do you mean, lack of a security proof? RFC 4279 might not cite
> one, but it's pretty obvious given the recent work on proving TLS
> secure what it is you need to do to get one. I can get confidentiality
> and authentication in the symbolic model immediately for RFC 4279, and
> more realistic models aren't that much harder. Of course, if this
> analysis wasn't done beforehand, it should have been.

  If such a proof would be enough to satisfy you over the security
of the TLS PSK ciphersuites then it would be enough to satisfy you
over the TLS-pwd ciphersuites.

  Dan.