Re: [TLS] Also, on client-random and server-random

Adam Langley <agl@google.com> Wed, 03 February 2010 10:16 UTC

DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=x3wQefL0X+t97n33IjTSMP/kskadmDW2OkskK9HB6m3hOx9mlBBeQFjC3MXIwoa13 aOvunz1BKJKK1uYW5vPQA==
MIME-Version: 1.0
In-Reply-To: <3561bdcc1002022022l1734b663wd8cfdb29d9be899@mail.gmail.com>
References: <3561bdcc1002022022l1734b663wd8cfdb29d9be899@mail.gmail.com>
Date: Wed, 03 Feb 2010 05:16:48 -0500
Message-ID: <a84d7bc61002030216p378256b1q308b6d7e8bc84b02@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Ravi Ganesan <ravi@findravi.com>
Content-Type: text/plain; charset="UTF-8"
Cc: tls@ietf.org
Subject: Re: [TLS] Also, on client-random and server-random
Precedence: list

On Tue, Feb 2, 2010 at 11:22 PM, Ravi Ganesan <ravi@findravi.com> wrote:
> FWIW, in my deconstruction of why these values exist, it seemed to me
> that if you ran the full handshake with only the server-random [...] you were ok

Consider a TLS connection using DH that I just sniffed from the network.

If there's no client random then what stops me from intercepting
future connections from the same client, to the same server and
replaying the server's side to the client? The server random would be
the same, as would the DH value and signature. I think, from a quick
thought experiment, that the master secret would end up the same and
the client would accept it. There's no reason that the client is
required to use a different DH public value.

AGL

[TLS] Also, on client-random and server-random Ravi Ganesan
Re: [TLS] Also, on client-random and server-random Adam Langley
Re: [TLS] Also, on client-random and server-random Ravi Ganesan