[TLS] TLS: Cryptographic Computations
Mark Dunn <mark.dunn@objectiveintegration.uk> Mon, 24 April 2017 12:21 UTC
Return-Path: <mark.dunn@objectiveintegration.uk>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460DB129413 for <tls@ietfa.amsl.com>; Mon, 24 Apr 2017 05:21:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 lgmlKcMi2Btc for <tls@ietfa.amsl.com>; Mon, 24 Apr 2017 05:21:29 -0700 (PDT)
Received: from mail.objectiveintegration.uk (objectiveintegration.uk [134.213.135.47]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1411A1314B4 for <tls@ietf.org>; Mon, 24 Apr 2017 05:21:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.objectiveintegration.uk (Postfix) with ESMTP id 7C0791A02E46 for <tls@ietf.org>; Mon, 24 Apr 2017 12:21:27 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at objectiveintegration.uk
Received: from mail.objectiveintegration.uk ([127.0.0.1]) by localhost (mail.objectiveintegration.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sax_pJKD_5MJ for <tls@ietf.org>; Mon, 24 Apr 2017 12:21:04 +0000 (UTC)
Received: from [192.168.110.3] (host86-179-241-20.range86-179.btcentralplus.com [86.179.241.20]) (Authenticated sender: mark.dunn@objectiveintegration.uk) by mail.objectiveintegration.uk (Postfix) with ESMTPSA id 2C0A11A01A96 for <tls@ietf.org>; Mon, 24 Apr 2017 12:21:04 +0000 (UTC)
From: Mark Dunn <mark.dunn@objectiveintegration.uk>
To: "tls@ietf.org" <tls@ietf.org>
Message-ID: <1989fd9d-d76c-bc0c-dce0-de47a76fe94c@objectiveintegration.uk>
Date: Mon, 24 Apr 2017 13:21:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Hrzs9bruGVnK4uUzovPR0xVjlbs>
Subject: [TLS] TLS: Cryptographic Computations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 24 Apr 2017 12:21:31 -0000
Sorry, I am having a dull moment trying to understand the
Transcript-hash, could someone help please?
From *TLS 1.3: section 4* I have:
enum {
client_hello(1),
server_hello(2),
new_session_ticket(4),
end_of_early_data(5),
hello_retry_request(6),
encrypted_extensions(8),
certificate(11),
certificate_request(13),
certificate_verify(15),
finished(20),
key_update(24),
message_hash(254),
(255)
} HandshakeType;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
select (Handshake.msg_type) {
case client_hello: ClientHello;
case server_hello: ServerHello;
case end_of_early_data: EndOfEarlyData;
case hello_retry_request: HelloRetryRequest;
case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest;
case certificate: Certificate;
case certificate_verify: CertificateVerify;
case finished: Finished;
case new_session_ticket: NewSessionTicket;
case key_update: KeyUpdate;
} body;
} Handshake;
and from *TLS 1.3: Section 4.1* I have:
uint16 ProtocolVersion;
opaque Random[32];
uint8 CipherSuite[2]; /* Cryptographic suite selector */
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
} ClientHello;
So combining the two for a ClientHello gives something like
struct {
HandshakeType msg_type = 0x01; /* handshake type client_hello*/
uint24 length = 0x001234; /* example of number of bytes in message */
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
...
} ClientHello;
} ClientHelloHandshake
In trying to understand the transcript hash, I read in *TLS **1.3:
section 7*
"Note that because the handshake transcript includes the random
values in the Hello messages, any given handshake will have different
traffic secrets"
This gives me a warm fuzzy feeling but *TLS 1.3: section 7.1* states
"Messages are the concatenation of the indicated handshake
messages, including the handshake message type and length fields, but
not including record layer headers."
I am guessing that "handshake message" is the ClientHelloHandshake I
created above and the "record layer headers" is the ClientHello,
Does this mean that the transcript-hash just uses the
ClientHelloHandshake.msg_type and ClientHelloHandshake.length
highlighted below?
struct {
*HandshakeType msg_type = 0x01; /* handshake type client_hello*/ uint24
length = 0x001234; /* example of number of bytes in message */*
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
...
} ClientHello;
} ClientHelloHandshake
If so, how does ClientHelloHandshake.ClientHello.random get included in
the handshake transcript?
- [TLS] TLS: Cryptographic Computations Mark Dunn
- Re: [TLS] TLS: Cryptographic Computations Eric Rescorla
- Re: [TLS] TLS: Cryptographic Computations Martin Thomson