Re: [TLS] Initial draft of DH-based key exchange

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Fri, 27 March 2015 15:31 UTC

Return-Path: <Kenny.Paterson@rhul.ac.uk>
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 709291ACE88 for <tls@ietfa.amsl.com>; Fri, 27 Mar 2015 08:31:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 bLwYIPltSeUO for <tls@ietfa.amsl.com>; Fri, 27 Mar 2015 08:31:39 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0699.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::699]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665011AD0D0 for <tls@ietf.org>; Fri, 27 Mar 2015 08:31:21 -0700 (PDT)
Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB381.eurprd03.prod.outlook.com (10.141.10.11) with Microsoft SMTP Server (TLS) id 15.1.125.19; Fri, 27 Mar 2015 15:27:54 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.01.0118.022; Fri, 27 Mar 2015 15:27:54 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [TLS] Initial draft of DH-based key exchange
Thread-Index: AQHQZW6JbdaeS/vEFE+Md9lDgM4HC50wcq0A//+zyYA=
Date: Fri, 27 Mar 2015 15:27:54 +0000
Message-ID: <D13ADBCE.43E69%kenny.paterson@rhul.ac.uk>
References: <CABcZeBNmufvfJ_2Nvw1YwvwGZ2u1=WvL45rPGJXARN1tAxOEfw@mail.gmail.com> <20150327150032.GA27825@LK-Perkele-VII>
In-Reply-To: <20150327150032.GA27825@LK-Perkele-VII>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.8.150116
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [31.133.136.113]
authentication-results: elisanet.fi; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB381;
x-microsoft-antispam-prvs: <DBXPR03MB381769B6223D2139DD0BEF4BC090@DBXPR03MB381.eurprd03.prod.outlook.com>
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(479174004)(51704005)(43544003)(24454002)(19580405001)(2900100001)(2950100001)(46102003)(122556002)(19580395003)(87936001)(92566002)(83506001)(2656002)(106116001)(36756003)(15975445007)(102836002)(86362001)(76176999)(50986999)(54356999)(62966003)(77156002)(66066001)(74482002)(77096005); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB381; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DBXPR03MB381; BCL:0; PCL:0; RULEID:; SRVR:DBXPR03MB381;
x-forefront-prvs: 0528942FD8
Content-Type: text/plain; charset="us-ascii"
Content-ID: <448581E96C0FD244A8A6F4B687BBF6DD@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2015 15:27:54.0797 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR03MB381
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Pow5quHt0d_0LGV0jzwdb5-b9lQ>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Initial draft of DH-based key exchange
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: Fri, 27 Mar 2015 15:31:50 -0000

Hi Ilari,

On 27/03/2015 10:00, "Ilari Liusvaara" <ilari.liusvaara@elisanet.fi> wrote:

>Sorry, this is quite long.
>
>Some background:
>
>Be very vary about "security proofs". The scope of how TLS is used is
>very broad. There have been numerious papers about "TLS proven secure"
>or "part X of TLS proven secure", that have later turned out to be
>irrelevant in practice due to insufficient scope (then there are
>ocassional security proofs that are just plain wrong).
>
>E.g. number of papers that overlooked that TLS MS is not CRK and
>the screwyness that this causes. E.g. breaking authentication.

No, the papers that I think you are referring to did not overlook that TLS
MS is not CRK. The problem is that they did not include renegotiation and
resumption in their scope, thereby not excluding the renegotiation attack
and the subsequent triple Handshake attack. So, yes, it's a scoping issue.
But no, it's not the thing you point to, it's that thing in combination
with other things.

Recent papers on this topic (one of which [0] I am a co-author on) are, I
believe, quite clear about their limitations of scope (my own paper [0],
for example, contains a whole section explaining what is not included in
the model and why that matters).

The limitation of scope does not mean the papers are useless. As you write
above, one just needs to be wary of over-interpreting what they say.

>Or
>paper that proved that "BEAST" is impossible... Only to turn out
>that it had made an assumption that BEAST attack broke.

I'm pretty familiar with the TLS and the relevant symmetric crypto
literature, but can't immediately identify your source here. If you can
give an exact reference, then we can debate what it did and did not say,
and thereby discuss the value of proofs and the limitations of models.

However, one thing I can say immediately is that the symmetric crypto
literature is pretty clear that IVs for CBC mode need to be random (see
[1], from 1997), and exhibited on-paper distinguishing attacks when they
are not (see Section 9 of [2], dating from 1995).

TLS 1.0 used predictable IVs despite clear warnings from the crypto
community. And predictable IVs enabled BEAST. Please don't shoot the
messengers.

>
>This problem is compounded by the fact that TLS is often used in
>environments like WWW, where attackers have unusual powers to
>exploit weaknesses that normally are not exploitable.
>
>The consequence is that even if some "security proof" says that
>it is okay to simplify system in some way, that simplification
>might still introduce vulernabilities.
>
>E.g. Consider TLS 1.3 draft -03 (I picked this because it is the
>earliest version that I think is implementable at all). It is a
>bit simpler than -04, and I think that it in some scope can be
>proven "secure". But it also has a known security hole (fixed in
>-04).
>
>OTOH, security proofs that produce conterexamples to security
>are useful to look at. The counterexample may or may not be
>relevant (telling which is likely nontrivial). If it is relevant
>or might be relevant, fixing the problem is worth it.
>
>
>Symmetric crypto is very fast, so a bit of extra hashing, PRFing
>or somesuch is pretty much insignificant compared to asymmeric
>things like computing signatures, DHFs or DHKGs.
>
>
>Short summary: Security proofs are useful, but relying on them
>is a very bad idea.

This I can almost agree with. I would put it this way: they provide a form
of assurance, but they should not be the only thing we rely on for
assurance.

Cheers

Kenny


[0] H. Krawczyk, K.G. Paterson and H. Wee. On the Security of the TLS
Protocol: A Systematic Analysis. In R. Canetti, J.A. Garay (eds.), CRYPTO
2013 (1), Lecture Notes in Computer Science Vol. 8042, pp. 429-448,
Springer, 2013

[1] M. Bellare, A. Desai, E. Jokipii, P. Rogaway. A Concrete Security
Treatment of Symmetric Encryption. FOCS 1997: 394-403

[2] P. Rogaway. Problems with proposed IP cryptography. Unpublished
manuscript, 1995. 
http://web.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.t
xt



>
>
>On Mon, Mar 23, 2015 at 08:36:41AM -0500, Eric Rescorla wrote:
>> Folks,
>> 
>> As an outcome of the interim, I was asked to write up an initial draft
>> of what this would all look like and post it to the list. You can find
>> such a draft at:
>> 
>> Git branch:
>> https://github.com/ekr/tls13-spec/tree/WIP_dh_based
>> 
>> Text file:
>> 
>>https://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tl
>>s13-dh-based.txt
>> 
>> HTML diff:
>> 
>>https://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tl
>>s13-dh-based-diff.html
>> 
>> 
>> Please note that this is a very rough draft and no doubt contains
>> a number of major errors (and certainly has seen no security review).
>> Please point these out to me if you find them, especially if they
>> impede understanding. Assuming that people are happy with this
>> general direction, I will clean it up and turn it into a PR.
>
>Okay, let's analyze what goes wrong (and fix the thing so it is easy
>to analyze):
>
>- For PSK/PFS/Static-DH "unified" scheme, there is _three_ inputs, not
>two.
>  1) PSK input.
>  2) PFS diffie-hellman input
>  3) Static Diffie-Hellman input.
>  -> 1 and 3 are not the same, even if they can't appear simultaneously!
>- For chaining keys from 0RTT (optional), you need _fourth_ input:
>  4) Static diffie-hellman from 0RTT.
>  -> Only computable if server accepts 0RTT.
>  -> Needed for gradual static-DH rollover.
>- The "handshake master secret" needs to be CR function of:
>  1) PFS diffie-hellman iput.
>  2) PSK input.
>  3) Static diffie-hellman from 0RTT (if exists)
>  4) Hash of *Hello and *KeyShare packets.
>  -> The reason for last is to defend against class of attacks including
>     Triple Handshake.
>- The "application master secret" needs to be CR function of:
>  1) handshake master secret.
>  2) Static Diffie-Hellman input.
>  -> The hash is not needed here (but can be included).
>  -> Can be different in both directions (which has some benefits,
>     in this case, the hash should be included).
>- The "exporter master secret" needs to be CR function of:
>  1) hanshake master secret.
>  2) Static Diffie-Hellman input.
>  3) The hash of *Hello, *Keyshare EncryptedExtensions and whatever is
>     carrying the server static DH key packets (more can be included
>     for a good measure).
>  -> The reason why EncryptedExtensions needs to be included is in case
>     it contains some extensions affecting TLS-Extractor. The reason
>     server static DH key is needed is again to guard against attacks
>     like THS.
>- The "resume premaster secret" needs to be CR function of:
>  1) hanshake master secret.
>  2) Static Diffie-Hellman input.
>  3) Hash of entiere handshake.
>  -> The reason why last needs needs to be entiere handshake is that
>     otherwise session may be resumed in inocnsistent state.
>  -> Also so that resumption doesn't destroy forward security.
>- Online signature (if present) TBS needs to include:
>  1) *Random
>  2) Purpose of signature (e.g. server PoP)
>  3) Ciphersuite #
>  4) Prf-hash of messages so far
>  -> *Random is to support privsep. Which is extremely useful even with
>     pure SW if you have MMU available (and most of the time you do).
>  -> Ciphersuite # is to pin the prf-hash algorithm (I think that is
>     just the simplest way).
>
>
>The "function of" listings above are what I consider the absolute
>minimum, that's the reason why "application master secret" hash input
>is not marked as needed. It can (and should) be included.
>
>Also, one should take care that none of the different secrets may
>end up being same (except by very bad luck).
>
>The only thing above -05 fails is "exporter master secret", which
>is the same as handshake master secret nor does it hash enough state.
>
>
>Also, other comments:
>- I consider HKDF-HMAC-SHA256 to be too weak.
>  -> I think it needs at least HMAC-SHA384 (also would just give one
>     prf-hash).
>  -> SHA384 is FASTER than SHA256 on modern hardware (that's why
>     SHA-512/256 exists). But SHA3-384 is slower than SHA3-256.
>- There is no need to intermingle static DH key with signature, even if
>  statid DH key exists.
>  -> Signatures work like in -05.
>  -> Can completely eliminate signature if one has fixed-DH cert (DHF
>     is WAY simpler than signature primitive).
>
>
>Also, will *server* 0RTT be supported, even with client authentication?
>It would set the following boundary conditions:
>- Server application keys can't include hashes of client certificate,
>  as those need to be computable immediately on server finished.
>- The same for exporter master secret.
>
>The restrictions here are:
>- Replay protection is provoded.
>- There is no authentication (the server hasn't heard client's
>  certificate, which keeps misuse potential way down).
>
>Usecases:
>- Protocol banners, feature negoitiation (ALPN doesn't scale!),
>  etc...
>
>
>Also regarding splitting application keys to directional ones:
>- Allows JIT derivation, eliminating temporarily invalid keys.
>- Allows rekeying (since requirement is no dead time and arbitrarily
>  delayed responses, as breaking this causes problems for all
>  applications).
>
>
>
>-Ilari
>
>_______________________________________________
>TLS mailing list
>TLS@ietf.org
>https://www.ietf.org/mailman/listinfo/tls