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