Subject: [TLS] TLS: Cryptographic Computations

From: Mark Dunn <[email-masked]>
Date: Mon, 24 Apr 2017 13:21:03 +0100

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?

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 24 Apr 2017 05:38:42 -0700

Hi Mark,

You might find it helpful to refer to:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/

Which contains test vectors.

On Mon, Apr 24, 2017 at 5:21 AM, Mark Dunn <
[email-masked]> wrote:

> Sorry, I am having a dull moment trying to understand the Transcript-hash,
> could someone help please?
>
> 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"
>
>     "Messages are the concatenation of the indicated handshake messages,
> including the handshake message type and length fields, but not including
> record layer headers."
>

I think this is where you are going wrong. Remember that in order to be
serialized on the wire the handshake message is wrapped in a TLSPlaintext
structure (and then potentially encrypted). It's those which are the record
headers and which are excluded. What is included is what you are calling
ClientHelloHandshake.

-Ekr

> ClientHelloHandshake.msg_type and ClientHelloHandshake.length highlighted
> below?
>
>    struct {

-Ekr

>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Apr 2017 08:16:59 +1000

> Which contains test vectors.

Caveat: that is specific to -18.  NSS hasn't been fully updated to
support -19 and until it does I won't be able to update the draft.