Re: [TLS] Computation of static secret in anonymous DH

Eric Rescorla <ekr@rtfm.com> Fri, 26 June 2015 17:09 UTC

Return-Path: <ekr@rtfm.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 AD77C1A8992 for <tls@ietfa.amsl.com>; Fri, 26 Jun 2015 10:09:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 0WyySQvkS6sa for <tls@ietfa.amsl.com>; Fri, 26 Jun 2015 10:09:37 -0700 (PDT)
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (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 CE5A21A898D for <tls@ietf.org>; Fri, 26 Jun 2015 10:09:36 -0700 (PDT)
Received: by wicgi11 with SMTP id gi11so23343258wic.0 for <tls@ietf.org>; Fri, 26 Jun 2015 10:09:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/T6p/m7BXG32wW++xinlH5dfpBFUgxiKO7Kj7BxF+k0=; b=mUic7jliqPz/OLf2lNL4/Czrlp5PNdTY7pgDphwXJcYz50FmovkHHbKMZIUpqav5xQ s9LbvbtyqzWYl3mqwm0snxQaCDyvs87eRGmU4DMa1n+2fZHjXD9/ViXNcv8BgniZ+sJ5 Nx7lCZ48UT819hfgzqTnX2D2TOkux595r5EwfG9ruRHaLmwN2zhfulFnLn8qo7DOq+Gb Mcgwmq/0xh17GniVPDXdmfRF2v3h/xU1wLbu5wAnZiZGEFKd+Fkth9uO8gJDvIUrHNUF sReZrkzYV1itWduUBgo5uw5Q6AwSSExTRSvliE/NpN0JZ7QT+v8xt4WFdeew+n2S2LDv vZsw==
X-Gm-Message-State: ALoCoQmhNaJbZbrmexb2CFkOowj2FmAagbedd+HaA6CEGqsT/qgUXJZaiht8PzNVeXySVNVvyOVW
X-Received: by 10.180.189.201 with SMTP id gk9mr6776343wic.53.1435338575498; Fri, 26 Jun 2015 10:09:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.95.211 with HTTP; Fri, 26 Jun 2015 10:08:55 -0700 (PDT)
In-Reply-To: <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> <20150626165415.GA28534@LK-Perkele-VII>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 26 Jun 2015 10:08:55 -0700
Message-ID: <CABcZeBOTMHVRNi-7JhKEz6KUt=U79SgiKPAmyqUeF3JauUt3Fw@mail.gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Content-Type: multipart/alternative; boundary=001a11c352a0ece4c505196ecde7
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/3VOATHEh1c-serPRTnOdWZ1facg>
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 17:09:39 -0000

Thanks for your review.

On Fri, Jun 26, 2015 at 9:54 AM, Ilari Liusvaara <
ilari.liusvaara@elisanet.fi> wrote:

> 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.
>

As I understand it, there are cryptographic logic reasons for this (again,
I'll defer to Hugo here). Maybe we should just define a new value
for TLS-Unique based on the exporter secrets?



> > > 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).


Sorry, I'm still not seeing how this works. If you replay 0-RTT, then don't
you by definition not know the original client DHE share (otherwise, why
replay), so how do you decrypt? Maybe I'm just being stupid here.



> 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.
>

Thanks. I'll give it a shot.



>
> 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?).
>

What did you have in mind for fixing this?



> 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).
>

Yeah, worth a shot.


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).
>

This was pointed out to me by Kartik so maybe I'm



> 11) Section "Random Number Generation and Seeding". Maybe change
> SHA-1 to SHA-256 and delete remark about PCs (it is throughly
> obsolete).


I am planning to rewrite much of this section.




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).
>

I would appreciate PRs for this.


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)
>

There are two cases:
1. You accept the 0-RTT, in which case you process them and then
include them in the session hash.
2. You reject the 0-RTT, in which case you can't even decrypt them
and then you don't include them in the session hash but instead
send a ServerHello right away.

With that said, I still haven't implemented this part (WIP!) and so
am not totally sure it works. Doe that make sense?

-Ekr