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 <
mark.d...@objectiveintegration.uk> wrote:
> 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,
>
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
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?
>
-Ekr
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
