Re: [TLS] Computation of static secret in anonymous DH
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Fri, 26 June 2015 16:54 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 A94191A893F for <tls@ietfa.amsl.com>; Fri, 26 Jun 2015 09:54:23 -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 kSDjPjo7N2bA for <tls@ietfa.amsl.com>; Fri, 26 Jun 2015 09:54:19 -0700 (PDT)
Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84B411A893E for <tls@ietf.org>; Fri, 26 Jun 2015 09:54:18 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 06BE41A2612; Fri, 26 Jun 2015 19:54:15 +0300 (EEST)
Date: Fri, 26 Jun 2015 19:54:15 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20150626165415.GA28534@LK-Perkele-VII>
References: <2AA11887-2F82-48EF-BD45-4D85CFA83847@qut.edu.au> <20150617082529.GA17280@LK-Perkele-VII> <CABcZeBNzzfxo+xQRrS=7-7C65kr3DqtJ5BHqTnt0mC8v-oFuUw@mail.gmail.com> <20150617150505.GA19959@LK-Perkele-VII> <CABcZeBN8m6f=F14Qx1QctMCoF7_LYNrf9D3HstoTZsK2orS1SA@mail.gmail.com> <20150626085008.GA25187@LK-Perkele-VII> <CABcZeBMHim=qBw9L_PG3C4+E=N6n=AdV1AoWN+_19zi84cJJgQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABcZeBMHim=qBw9L_PG3C4+E=N6n=AdV1AoWN+_19zi84cJJgQ@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/_4Oln7xYAo4uPR5mFgKQLpIHOB0>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Computation of static secret in anonymous DH
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: <https://mailarchive.ietf.org/arch/browse/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, 26 Jun 2015 16:54:23 -0000
On Fri, Jun 26, 2015 at 05:55:21AM -0700, Eric Rescorla wrote: > On Fri, Jun 26, 2015 at 1:50 AM, Ilari Liusvaara < > ilari.liusvaara@elisanet.fi> wrote: > > > 1) xSS is used as direct input to HKDF-Expand, so one would presume > > it should be HKDF-Extract output (AFAIK, HKDF-Extract and HKDF-Expand > > are supposed to be paired). HKDF-Extract does not take label nor > > length. > > > > 2) Same as above for xES. > > > > 3) Same as above for master_secret. > > > > 4) Why does master_secret derivation take xSS and xES instead of > > SS and ES directly (especially if xSS and xES are supposed to be > > HKDF-Extract outputs)? > > > > 4) Why is finished independent of ES (IIRC, it did depend on it > > in earlier version)? > > > > i'm going to refer these to Hugo, as they were his suggestion. Also, TLS 1.2 had tls-unique also be secret (but one would have to really misuse it for that to matter). With finished just depending on SS, secrecy might fail. Probably nobody uses tls-unique the wrong way, but then, nobody probably thought somebody uses tls-extractor outputs as nonces in TLS 1.2 (I know two (now deprecated) protocols that do that, both took a nasty hit from THS). > > 5) Application data uses xES as secret. AFAICT, leads to an attack. > > Should be master_secret (IIRC, was that way in earlier version)? > > > > This is a typo. Will fix. Remember, this is a WIP branch. :) > > With that said, I'd be interested in hearing what the attack is. Pretty weak one, but replaying 0-RTT and then decoding what the server sends back (which can be quite revealing about what the 0-RTT payload was). > > 7) I think there should be helper function defined to do the > > label zero-padding, instead of it being just a note (just for > > clarity). > > Hmm... Can you suggest text? Do you think we should do this > for the signature context as well? Maybe something like: HKDF-Extract-Label(secret, label, seed, length) = HKDF-Extract(secret, label + "\0" + seed, length) Where label is ASCII label with no NUL bytes and "\0" is the NUL byte. And then use that. Might be worthwhile doing for digital signatures as well, but it isn't clear how to best denote it, since digitally-signed works as a macro. Some more stuff: 8) Client and Server certificate verify sign hash of handshake (using prf-hash) but don't indicate what hash was used. Can have nasty effects if the prf-hash is ever really broken and replacement has the same bitlength (yes, we know that broken hashes should be de-implemented, except this doesn't seem to happen as fast as we would like. RC4, MD5 and EXPORT anybody?). 9) Might make sense to replace the early_data_allowed in ServerCofiguration with a bitfield listing acceptable uses (some other uses might be ClientAuthentication and ServerAuthentication). 10) "Finally, note that if the server key is compromised, and client authentication is used, then the attacker can impersonate the client to the server (as it knows the traffic key)." ... How does that work? I tried to figure that out, the problem I hit was that I couldn't figure out how to compute ES on server side of MITM (without also having compromised some signed client's key). 11) Section "Random Number Generation and Seeding". Maybe change SHA-1 to SHA-256 and delete remark about PCs (it is throughly obsolete). 12) "Implementation Pitfalls". Add rejecting incorrect sequence of handshake message types. There have been _multiple_ catastrophic security failures from getting this wrong. 13) 'the DSA "k" parameter'. Maybe change that to 'the ECDSA "k" parameter' (DSA is pretty much obsolete, or better, use deterministic ECDSA). 14) 'In order to allow servers to readily distinguish between messages sent in the first flight and in the second flight (in cases where the server rejects the EarlyDataIndication extension), the client MUST send the handshake messages as content type "early_handshake"' ... How does that work? Without explicit end of transmission incidation, the server doesn't know when to send ServerHello, and it needs to know that in order to properly lay out its session_hash (and not including those in session_hash needs _serious_ analysis). -Ilari
- [TLS] Computation of static secret in anonymous DH Douglas Stebila
- Re: [TLS] Computation of static secret in anonymo… Ilari Liusvaara
- Re: [TLS] Computation of static secret in anonymo… Eric Rescorla
- Re: [TLS] Computation of static secret in anonymo… Ilari Liusvaara
- Re: [TLS] Computation of static secret in anonymo… Eric Rescorla
- Re: [TLS] Computation of static secret in anonymo… Ilari Liusvaara
- Re: [TLS] Computation of static secret in anonymo… Eric Rescorla
- Re: [TLS] Computation of static secret in anonymo… Ilari Liusvaara
- Re: [TLS] Computation of static secret in anonymo… Eric Rescorla
- Re: [TLS] Computation of static secret in anonymo… Nico Williams
- Re: [TLS] Computation of static secret in anonymo… Eric Rescorla
- Re: [TLS] Computation of static secret in anonymo… Hugo Krawczyk
- Re: [TLS] Computation of static secret in anonymo… Eric Rescorla
- Re: [TLS] Computation of static secret in anonymo… Ilari Liusvaara
- Re: [TLS] Computation of static secret in anonymo… Eric Rescorla
- Re: [TLS] Computation of static secret in anonymo… Hubert Kario
- Re: [TLS] Computation of static secret in anonymo… Ilari Liusvaara
- Re: [TLS] Computation of static secret in anonymo… Nico Williams