Re: [TLS] rfc7366: is encrypt-then-mac implemented?

[[e-mail] (Martin Rex)]

Yngve,

Yngve N. Pettersen wrote:
> 
> The way a TLS Protocol record is defined in previous versions (Using TLS  
> 1.2), before this update is, can a generic way be rewritten as:
> 
>    struct {
>         ContentType type;
>         ProtocolVersion version;
>         opaque record_data<0..maxlength>
>    } TLS_Record;
> 
> This is how all clients and servers will parse current SSL and TLS  
> versions' records on the wire, and also how all the intermediate servers  
> (the ones that are causing concern for version rollback recovery) will be  
> parsing the TLS traffic.

Thanks for your elaborate discussion.

I agree with many parts of your root cause analysis why the content
of rfc7366 is a failure (beyond fixing through the errata process).

I wrote a similar (much less elaborate) observation to Peter a day
earlier (in a private mail), that the root cause of the confusion
is likely the goof of the original SSLv3 and successor specs
in failing to correctly specify the outer TLS protocol PDU
and properly modeling of the inner PDU variations within
the correct framework.

   struct {
        ContentType type;
        ProtocolVersion version;
        opaque record_data<0..(2^14+2048)>
   } TLS_Record;


It doesn't really matter whether the seriously misleading and
backwards-incompatible protocol in rfc7366 could be hacked to
produce the same "bits-on-the-wire" as what was actually intended
protocol-wise, by frobbing the semantics and content of the
length field of the redefined rfc7366 TLSCiphertext and frobbing
the MAC computation.


> 
> The field record_data containing a strucure of exactly the length of  
> record_data
> 
>    struct {
>      select(encryption_mode) {
>         case plaintext: TLS_Plaintext_data;
>         case stream_encrypted: TLS_Stream_Encrypted_data;
>         case block_encrypted: TLS_Block_Encrypted_data;
>      }
>    } TLS_Record_payload;

Your picture is lacking the TLSCompressed structure, which (although 
not used very often these days) is still a regular part of the
SSLv3 and TLSv1.[012] protocols.


One of my complaints about rfc7366 was to redefine the GenericBlockCipher
PDU in a backwards-incompatible fashion, and actually use *TWO DIFFERENT*
PDUs, rather than a single combined one.  It is extremely silly to
carry through the IV-less TLSv1.0 PDU on a backwards-incompatible
PDU change, because this will require _more_ code and _repeat_ a
known security problem in an alleged protocol security fix.


-Martin