Re: [TLS] confirming the room’s consensus: adopt HKDF PRF for TLS 1.3
Michael StJohns <msj@nthpermutation.com> Mon, 27 April 2015 17:18 UTC
Return-Path: <msj@nthpermutation.com>
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 6E1911A8AC2 for <tls@ietfa.amsl.com>; Mon, 27 Apr 2015 10:18:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.228
X-Spam-Level:
X-Spam-Status: No, score=-0.228 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, URI_NO_WWW_INFO_CGI=2.071] 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 rKXH1-WFPfqc for <tls@ietfa.amsl.com>; Mon, 27 Apr 2015 10:18:08 -0700 (PDT)
Received: from mail-vn0-f47.google.com (mail-vn0-f47.google.com [209.85.216.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECA031A8A60 for <tls@ietf.org>; Mon, 27 Apr 2015 10:18:03 -0700 (PDT)
Received: by vnbf190 with SMTP id f190so12791594vnb.1 for <tls@ietf.org>; Mon, 27 Apr 2015 10:18:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=G5CsAZDwx4Ldul6gRt81YTlANq4FIQJab66BXoldUw0=; b=lyRtswp+bqB9cpEc2OJdnqnByrgGkBZwrNFkuAhB7gFyvZzpdfDHq6z4FWPe0fA3Av BSTy78rffiyaXped4OMZRr4j51MsWLU1RZWo6/TN+ljFQB7t4lbENw3ENJtyyFe5IZDb JT6rICU2Y6J6YMjY2NFwhb5RcRfs03O0VxckI58MlHhGh0ySM4xYRTGouJcnoz2nrvHK 0uWdAIzqfTtl3suVGIEXxarSN0XNFRkq53cuCot1yEKwD+S5/fu2DXNzoKJtk+7aPGky f31SVqzSIFr6L0G/AAU7JxolGHmLoYmCuQPR0Dbau4HPHSDukzhCSSET6Fw7WiodfP1u YoEA==
X-Gm-Message-State: ALoCoQnJ1Lqc4N5AaqgtPToLiDnGuZTRBKljfpjqkJMSBPQHV0AQqtgzo2v51W9L5MXWe/cdgZTC
X-Received: by 10.52.114.42 with SMTP id jd10mr28805467vdb.90.1430155083109; Mon, 27 Apr 2015 10:18:03 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:84:8d57:b850:1714:c34a? ([2601:a:2a00:84:8d57:b850:1714:c34a]) by mx.google.com with ESMTPSA id c7sm26925304vdw.16.2015.04.27.10.18.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 10:18:02 -0700 (PDT)
Message-ID: <553E6F4A.6080103@nthpermutation.com>
Date: Mon, 27 Apr 2015 13:18:02 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Hugo Krawczyk <hugo@ee.technion.ac.il>
References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <F7F3EB83-FEA2-477C-8810-38C49B71C977@ieca.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <CACsn0cm5A50dP4JDKq9R0XdB83hyzPPLQHAMnUcXFb+DCSwV7g@mail.gmail.com> <55392B08.6020304@nthpermutation.com> <CADi0yUPTixoesXkgd=HYe_+ua_+=_UfcDBSndCgdh1usTzNpzQ@mail.gmail.com> <553D3572.6040408@nthpermutation.com> <CADi0yUOnsD0Sasq7dRTbRpUm9jTg-uf+vjkkpMCxxsKXH0kqMw@mail.gmail.com>, <553D4FF7.8080700@nthpermutation.com> <9A043F3CF02CD34C8E74AC1594475C73AB0084CA@uxcn10-tdc05.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB0084CA@uxcn10-tdc05.UoA.auckland.ac.nz>
Content-Type: multipart/alternative; boundary="------------090300010509050801060705"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/d5DDwc_g-8vqVsAv5dmvfcSjzjM>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] confirming the room’s consensus: adopt HKDF PRF for TLS 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, 27 Apr 2015 17:18:11 -0000
On 4/27/2015 2:06 AM, Peter Gutmann wrote: > Michael StJohns <msj@nthpermutation.com> writes: > > >This isn't about TLS specifically, but about how an HSM makes sure an > >attacker can't extract TLS keys. > > Stepping back a bit in order to actually see the woods here, why is > this an > issue? Anyone who's using hardware for performance reasons will offload > everything to an SSL terminator, almost everyone else who doesn't want > to do > that will do the crypto on the host, those worried about private-key > security > will store the server key in an HSM but not do the bulk crypto there > because > doing it on the host is typically much faster, and even if you do use > PKCS #11 > to do your bulk crypto for TLS, any attacker who's in a position to > extract > the session keys from an HSM via a PKCS #11 mechanism has to control > the host > it's talking to, in which case they've got direct access to the plaintext > anyway. > > I realise that it's always possible to invent some scenario in which > this is > an issue, but how much of a real-world impact does it actually have? Bob > Relyea suggested TLS 1.2 PRF mechanisms in 2007 on the old Cryptoki > list (and > it seemed his motivation for that was the need to be able to support it in > Mozilla's softoken implementation, for which he needed a defined PKCS #11 > mechanism), and OASIS is just getting around to finalising the > standard for > them now, seven years later. This would seem to indicate that the actual > industry demand for this (not the hypothesised need but the real-world > demand) > is a giant who-cares. > > So as I've already said earlier in this discussion, create the best > mechanism > that's a combination of good crypto design principles and ease of > implementation/deployment for existing implementations, and if someone > specifically wants to do it in an HSM they'll have to accept that > they're the > odd corner case and deal with it. > > Peter. All of these are fair points - but miss the point that only small changes to what we do in TLS will permit securing all of the key material in the HSM and will not add to the cost of a software implementation. Whereas, if you don't do anything, (or you do things like generating IVs as secret material), then the only choice is for the HSM to implement a highly specific TLS crypto system and mark keys as only for use in TLS. Even then, I can't see how to reconcile security between that and the need for exporters given the current definitions. With respect to TLS1.2 PRF et al in PKCS11 - imputing the delay in adding TLS1.2 to the spec to a general lack of a desire to do this in hardware is probably at best only partially correct. A more correct assignment of blame is probably due to the small uptake of TLS1.2 deployments. See https://jve.linuxwall.info/blog/index.php?post/TLS_Survey - I'm not sure how valid the methodology is, but that's 33% in January 2014 and apparently a lot less in 2010 - see page 37 of http://blog.ivanristic.com/Qualys_SSL_Labs-State_of_SSL_2010-v1.6.pdf. I have this suspicion that Heartbleed is at least a substantial driver for the increase. Currently (TLS1.2 and before), generic HSMs can protect the server key pair and, once inserted in the HSM, the session keys. What they can't protect are the steps between. That's an artifact of: use of the same key for both MAC and key expansion and pseudorandom bit generation (e.g. Initial IV and Session Nonce generation); the lack of cryptographic binding between the length and type of the output keys and the key stream generation in the key expansion formation. In any event, there's something of a chicken and egg problem. People don't implement TLS using hardware because the hardware doesn't exist. HSM vendors don't implement TLS (or only implement PKCS11's definition of TLS) because the user base isn't there. Both wait for the other. That also applies between versions - finding a good implementation of TLS1.2 was dependent on there being a market for it and that market took a while to develop as TLS1.0 and 1.1 were working fine for the generic customer (until they weren't....). Finally, someone somewhere has figured out that they don't need to break into a system and steal the plain text if they can just get the system to send it the keys as they generate them. I have no idea if anyone has accomplished such attack successfully, but it's one that bothers me because of how hard it might be to detect and ultimately protect against. The only real defense against such an attack is a security module hardened against over the air attacks - hardening the system only gets you so far. I've pushed hard on this because if it isn't fixed in TLS1.3, it will be at least 10 years to the next deployment iteration. It seems silly to do something that can't be secured if it's relatively easy to do something that can be secured. Later, Mike
- [TLS] confirming the room’s consensus: adopt HKDF… Sean Turner
- Re: [TLS] confirming the room’s consensus: adopt … Daniel Kahn Gillmor
- Re: [TLS] confirming the room’s consensus: adopt … Nikos Mavrogiannopoulos
- Re: [TLS] confirming the rooms consensus: adopt … Dan Harkins
- Re: [TLS] confirming the room’s consensus: adopt … Russ Housley
- Re: [TLS] confirming the room’s consensus: adopt … Brian Smith
- Re: [TLS] confirming the room’s consensus: adopt … Ilari Liusvaara
- Re: [TLS] confirming the room’s consensus: adopt … Sean Turner
- Re: [TLS] confirming the room’s consensus: adopt … Sean Turner
- Re: [TLS] confirming the room’s consensus: adopt … Yoav Nir
- [TLS] confirming the room’s consensus: adopt HKDF… Peter Gutmann
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Sean Turner
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Nikos Mavrogiannopoulos
- Re: [TLS] confirming the room’s consensus: adopt … Ilari Liusvaara
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Watson Ladd
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Hugo Krawczyk
- Re: [TLS] confirming the room’s consensus: adopt … Ilari Liusvaara
- Re: [TLS] confirming the room’s consensus: adopt … Andrey Jivsov
- Re: [TLS] confirming the room’s consensus: adopt … Ilari Liusvaara
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Hugo Krawczyk
- Re: [TLS] confirming the room’s consensus: adopt … Hugo Krawczyk
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Watson Ladd
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Peter Gutmann
- Re: [TLS] confirming the room’s consensus: adopt … Salz, Rich
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Hugo Krawczyk
- Re: [TLS] confirming the room’s consensus: adopt … Ilari Liusvaara
- Re: [TLS] confirming the room’s consensus: adopt … Sean Turner
- Re: [TLS] confirming the room’s consensus: adopt … Eric Rescorla