Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard

[[e-mail] (Martin Rex)]

Michael Clark wrote:
> 
>     4). MUST Include the entire handshake record layer rather than
> content in the veryify_data hash


Excuse me while I panic.

There seems to be a complete misunderstanding of the TLS protocol.
The TLS record protocol was *INTENTED* to be independent of the
protocol inside (handshake, appdata, alerts, ccs).


> --- a/draft-ietf-tls-tls13.md
> +++ b/draft-ietf-tls-tls13.md
> @@ -2674,7 +2674,7 @@ Structure of this message:
>  
>  
>  verify_data
> -:      PRF(hs_master_secret, finished_label, Hash(handshake_messages))
> +:      PRF(hs_master_secret, finished_label, Hash(handshake_records))
>               [0..verify_data_length-1];


This would be totally wrong.

The TLS record layer protocol was designed to be independent of the
protocols within ON PURPOSE.  In particular, the TLS record protocol
is independent from the protocol within about fragmenting and coalescing
data.

Look at the TLS protocol handshake flowchart:

https://tools.ietf.org/html/rfc2246#page-31

     Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data


How the TLS record layer packages the initial response from the server
to the client into TLS records, is entirely up to the TLS record layer
and irrelevant to the computation of handshake message hash and the
TLS finished handshake messages:

                                                     ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                                 ServerHelloDone

i.e. whether each handshake message is packaged into a seperate TLS record,
whether some or all of them are stuffed into one record -- and where
exactly the fragmentation will occur if the maximum TLS plaintext size
(2^14 = 16384 bytes) is reached, is entirely at the discretion of the
TLS record layer, and the TLS handshake protocol engine does not know
or care about it.   This complete independence is likely also the
reason why ChangeCipherSpec is a seperate content type (this forces
flushing of the record layer buffers, because the record layer might
want to coalesce handshake messages, e.g. in the abbreviated handshake
for the server response:

      Client                                                Server

      ClientHello                   -------->
                                                       ServerHello
                                                [ChangeCipherSpec]
                                    <--------             Finished


While this might not be an issue for TLSv1.3 when Renegotiation is dropped
-- completely ignoring additional HelloRequests from the server would
not be possible if the handshake message hash would cover *EVERYTHING*
rather than only the handshake messages that belong to the current
handshake.


-Martin