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

From: "Yngve N. Pettersen" <[email-masked]>
Date: Sat, 01 Nov 2014 20:25:32 +0100

Hi,

Warning, long post.

For reference, I have tried to implement RFC 7366 in my TLS Prober, but I  
have not been able to establish a connection with the "eid" server. It  
seems to have some non-standard requirements to the client that AFAICT  
have not been documented anywhere.

On Wed, 29 Oct 2014 15:38:41 +0100, Peter Gutmann  
<[email-masked]> wrote:

> Manuel Pégourié-Gonnard <[email-masked]> writes:
>
>> What I'm doing to get this is interpret TLSCipherText.length exactly as  
>> it is
>> defined in RFC 5246 (6.2.3.2, page 22):
>>
>>   The encrypted data length (TLSCiphertext.length) is one more than the
>>   sum of SecurityParameters.block_length, TLSCompressed.length,
>>   SecurityParameters.mac_length, and padding_length.
>>
>> Apparently to interoperate with the implementation at eid.vx4.net (and  
>> with
>> OpenSSL 1.1.0-dev) one needs to rather interpret it as excluding
>> SecurityParameters.mac_length. I couldn't find this explicitly stated
>> anywhere.
>
> Section 3 of RFC 7366 says:
>
>   In [2] notation the overall packet is then:
>
>    struct {
>           ContentType type;
>           ProtocolVersion version;
>           uint16 length;
>           GenericStream/BlockCipher fragment;
>           opaque MAC;
>           } TLSCiphertext;
>
>    This is identical to the existing TLS layout with the only difference
>    being that the MAC value is moved outside the encrypted data.

I am starting to wonder if the confusion about this spec update is partly  
due to the way the record structure is defined, with the length separate  
 from the data vectors. This separation have been a problem in connection  
with at least some extensions.

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.

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;

   struct {
      opaque plaintext[TLS_Record.record_data.length];
   } TLS_Plaintext_data;

   stream-ciphered struct {
      opaque [TLS_Record.record_data.length-MAClength];
      opaque MAC[MAClength];
   } TLS_Stream_Encrypted_data;

   struct {
      opaque IV[SecurityParameters.record_iv_length];
      block_encrypted_stream  struct {
         opaque  
[TLS_Record.record_data.length-SecurityParameters.record_iv_length-MAC-paddinglength-1];
         opaque MAC[MAClength];
         uint8 padding [paddinglength];
         uint8 paddinglength;
      } encrypted;
   } TLS_Block_Encrypted_data;

With RFC7366 the format for the encrypted record payloads got changes, and  
it seems to me that the problem is a disagreement of what the length field  
in the TLSCipherText record applies to.

In the following I will assume that we (the TLS WG) while implementing  
peers that understand the Encrypt then MAC record format, also wants to  
Maintain backwards compatibility with all existing infrastructure (such as  
firewalls) that processes the TLS ciphertext records, but which do not  
know about RFC 7366.

Given these requirment, I think the TLS_Record_payload structure have to  
be redefined as

   struct {
     select(encryption_mode) {
        case plaintext: TLS_Plaintext_data;
        case stream_encrypted: TLS_EtM_Stream_Encrypted_data;
        case block_encrypted: TLS_EtM_Block_Encrypted_data;
     }
   } TLS_Record_payload;

   struct {
      stream-ciphered opaque  
fragment[TLS_Record.record_data.length-MAClength];
      opaque MAC[MAClength]
   } TLS_EtM_Stream_Encrypted_data;

   struct {
      opaque IV[SecurityParameters.record_iv_length];
      block-ciphered struct {
        opaque  
fragment[TLS_Record.record_data.length-SecurityParameters.record_iv_length-MAC-paddinglength-1];
        uint8 padding [paddinglength];
        uint8 paddinglength;
      } encrypted;
      opaque MAC[MAClength];
   } TLS_EtM_Block_Encrypted_data;

I think one thing that is to be determined is whether this rewritten  
structure definitions accurately describes both the old format and the new  
RFC 7366 format. Do they?

If RFC 7366 means to say that the MAC field is no longer part of the  
record_data field (and not counted in the length field), then that is  
going to cause trouble, because processors that are not aware of the  
extension will then read the first bytes of the MAX as the ContentType  
field and the version field, probably resulting in a connection closure.

The second issue that seems to have developed is which value to use as the  
length part of the MAC calculation.

RFC 7366 version:

    MAC(MAC_write_key, seq_num +
        TLSCipherText.type +
        TLSCipherText.version +
        TLSCipherText.length +
        IV +
        ENC(content + padding + padding_length));

Adapted to my rewritten structure the question is if the MAC (for block  
cipher encryption) is calculated as

    MAC(MAC_write_key, seq_num +
        TLS_Record.type +
        TLS_Record.version +
        TLS_Record.record_data.length +
        IV +
        ENC(content + padding + padding_length));

or

    MAC(MAC_write_key, seq_num +
        TLS_Record.type +
        TLS_Record.version +
        TLS_EtM_Block_Encrypted_data.fragment.length +
        IV +
        ENC(content + padding + padding_length));

As written, as I understand it, and assuming compatibility with ignorant  
intermediates, RFC 7366 specifies the first formula.

However, I have the impression that some think that either 1) the MAC  
field is not part of the bytes counted as TLSCipherText.length or 2) the  
length field in the MAC is really the length of the fragment field.

IMO case 1 will lead to interoperability problems with intermediates, and  
case 2 is not what the specification says if we assume interoperability.

I think that before we continue the discussion we need to decide what the  
record format is on the wire, and if it is compatible with the old format,  
or not. Then we need to decide which value is used in the MAC formula.

My suggestion for an answer to the first question is that we have to  
maintain backwards compatibility with ignorant intermediates, which means  
that TLSCipherText.length MUST count the MAC bytes, not just the fragment  
(including padding).

Regarding the second question, IMO it does not really matter much which  
value is used. However, it is probably easier to use the length of the  
encrypted block, rather than TLSCipherText.length, since  
TLSCipherText.length have to be calculated instead of derived from the  
MACed encrypted block.

Given the current confusion we need at least an errata that accurately  
specifies which values include which data.

However, given that such changes may modify the meaning more than a normal  
errata do, perhaps a better idea is a new RFC that either replace RFC 7366  
or one that specifies a new extension ID and deprecate the old one, so  
that we reduce the potential for confusion among implementations? After  
all, some implementers might miss the existence of the errata, and in this  
case the errata would be important for the proper understanding of the  
specification.

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Sat, 01 Nov 2014 22:32:17 +0100

> have not been documented anywhere.
IIRC, I found out that it doesn't like 03 00 as the record-level version number
in the ClientHello. I was able to connect by setting the minimum version of my
test client to TLS 1.0, which upped the record-level version number of the
ClientHello to 03 01.

> with at least some extensions.
Out of curiosity, which ones?

> (the ones that are causing concern for version rollback recovery) will be  
Agreed so far. (And AFAIK all implementations of RFC 7366 agreed on this point.)

>         case block_encrypted: TLS_Block_Encrypted_data;
And AEAD, and plaintext can be seen as a special case of Stream.

> in the TLSCipherText record applies to.
As far as I'm concerned, I've always been convinced that it was the length of
the rest of the record (in that case, padded-encrypted stuff plus unencrypted
MAC), and I've only mentioned alternative hypothesis as a sort of reductio ad
absurdum.

>    } TLS_EtM_Block_Encrypted_data;
I find this one complicated: to me it looks more natural to defined the length
of the record as content length + padding length + etc. than otherwise.

> RFC 7366 format. Do they?
I guess they do, but I agree with Peter that such extensive redefinitions are
not really suited to an erratum.

> field and the version field, probably resulting in a connection closure.
I think it's pretty clear for everyone RFC 7366 never intended to say that.

> length part of the MAC calculation.
Which was actually the only issue causing interop failures.

>         ENC(content + padding + padding_length));
If I follow correctly your new notation, the second one is not what the RFC
meant: the length should be the length of
TLS_EtM_Block_Encrypted_data.encrypted, not fragment (ie including the padding).

> intermediates, RFC 7366 specifies the first formula.
That's what I first thought too, but it turns out it was not the intention of
the RFC and most importantly, it's not what the implementations deployed so far do.

Unless you're aware of an implementation that is deployed and incompatible with
the eid server (which I seriously hope not), there's not point discussing which
choice makes the most sense: it's to match the deployed implementation(s).

> that TLSCipherText.length MUST count the MAC bytes, not just the fragment  
I think we all agree, and always agreed, on this one.

> TLSCipherText.length have to be calculated instead of derived from the  
Yes. (Just nitpicking: when doing authenticated decryption, it's the other way:
the length of the encrypted block needs to be computed, while the length of the
record is readily available, so the situation is quite symmetric actually.)

> specifies which values include which data.
I'm under the impression that Peter's paragraph in [1] suits this goal.

[1] http://mailarchive.ietf.org/arch/msg/tls/3NOHlIUShLo9AAzXx4t2u7QV8Sw

Do you agree? I reproduce the specific paragraph here for convenience's sake:

  Note that the value of the 'uint16 length' field in the TLSCiphertext record
  differs from the length value used in the MAC calculation, since the
  TLSCiphertext record contains both the ciphtertext and the MAC, while the
  MAC calculation is performed only over the ciphertext.  So the length value
  encoded in the TLSCiphertext record is 'length' while the length value used
  in the MAC calculation is 'length - SecurityParameters.mac_length'.

> that we reduce the potential for confusion among implementations?

Unless we have reasons to think there already are mutually incompatible
implementations in the wild, I don't think it's worth the trouble allocating a
new extension, which would delay adoption of the feature, while we want it
available and actually usable sooner rather than later.

> After  
I'd expect any half-serious implementer to test interop with at least one other
implementation before releasing. Unfortunately, experience proves people are not
always serious about it. I honestly don't know.

Manuel.

---

From: "Christian Kahlo" <[email-masked]>
Date: Sat, 1 Nov 2014 22:50:16 +0100

> For reference, I have tried to implement RFC 7366 in my TLS Prober, but
> I have not been able to establish a connection with the "eid" server.
> It seems to have some non-standard requirements to the client that
> AFAICT have not been documented anywhere.

More details please.
What did the server respond, how did you try to connect?

---

From: "Christian Kahlo" <[email-masked]>
Date: Sat, 1 Nov 2014 22:58:23 +0100

> IIRC, I found out that it doesn't like 03 00 as the record-level
> version number in the ClientHello. I was able to connect by setting the
> minimum version of my test client to TLS 1.0, which upped the record-
> level version number of the ClientHello to 03 01.

Yes, SSLv3 is explicitly unsupported. As there is no handshake back-
ward compatibility with SSLv3 "03 00" is forbidden at the record level.

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Sat, 01 Nov 2014 23:11:05 +0100

[changing the subject line this it has nothing to do with RFC 7366]

> ward compatibility with SSLv3 "03 00" is forbidden at the record level.
I certainly agree about not supporting SSLv3 at all, but I'm not convinced
rejecting record-level 03 00 this is the best thing to do . In practice this
mostly means rejecting clients that want to interoperate with old servers.

My interpretation of the last paragraph of RFC 5246 E.1 below

   TLS clients that wish to negotiate with older servers MAY send any
   value {03,XX} as the record layer version number.  Typical values
   would be {03,00}, the lowest version number supported by the client,
   and the value of ClientHello.client_version.  No single value will
   guarantee interoperability with all old servers, but this is a
   complex topic beyond the scope of this document.

is life is already complicated enough for clients, and servers should help them
by accepting any half-sensible value here (it's always time to be stricter later).

Just my opinion.

Manuel.

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Sat, 01 Nov 2014 23:23:22 +0100

On Sat, 01 Nov 2014 22:32:17 +0100, Manuel Pégourié-Gonnard  
<[email-masked]> wrote:

>> I

As I recall (don't have the branch checked out at the moment) my prober  
tested multiple variations and versions, and never got a connection  
established, with or without extensions enabled

> Out of curiosity, which ones?

I ran into the issue when writing the multiple certificate status  
extension, and also noticed it in the Server Name Indication extension for  
new types of names, although that had already been noticed and fixed in an  
updated spec.

> Agreed so far. (And AFAIK all implementations of RFC 7366 agreed on this  

Given the discussion I noticed, which seemed to be a discussion about  
whether the MAC length was included in the TLSCipherText.length or not, I  
thought it best to have a structure for discussion that made it clear. The  
goal of the restatement was to remove as much ambiguity as possible

> And AEAD, and plaintext can be seen as a special case of Stream.

I needed some cases to show the variation, and did not mean it to be  
exhaustive.

> MAC), and I've only mentioned alternative hypothesis as a sort of  

To me, before I lost track of all the details in the back and forth, it  
seemed like that was considered a possible contender.

> not really suited to an erratum.

The restatement is not intended for any erratum, but as a way to better  
show the details of how the message is structured, which numbers go where,  
so that it is clearer which numbers come from where.

> I think it's pretty clear for everyone RFC 7366 never intended to say  

I hoped so, but given all the back and forth, particularly about what was  
included in TLSCipherText.length, I was not sure if some might think that.  
Just to be on the safe side I think TLSCipherText.length should have a  
comment in the structure as being length of fragment+padding+mac

> TLS_EtM_Block_Encrypted_data.encrypted, not fragment (ie including the  

Sorry, I should have used TLS_EtM_Block_Encrypted_data.encrypted.length in  
the second one. Hope that makes it clearer.

> choice makes the most sense: it's to match the deployed  

I am currently not aware of any testable servers, except the eid server,  
and I have not been able to get more than protocol errors or handshake  
errors from it, and I am not sure what it is objecting to.

> I think we all agree, and always agreed, on this one.

Good.

>   in the MAC calculation is 'length - SecurityParameters.mac_length'.

It seems to describe the conclusions above, indeed, but personally I would  
prefer that the formula should not reference TLSCiphertext.length at all,  
but instead refer to the length of the field with the encrypted data, or  
specifically defined as avariable in a separate formula as 'length -  
SecurityParameters.mac_length'. Less chance of confusion, that way, and  
having multiple values of a variable is never a good idea, unless it is  
inside an algorithm that explicitly update the values as part of a step,  
after it was used for something.

> available and actually usable sooner rather than later.

I'm just putting it on the table as a (worst case) possibility; an  
intermediate solution might be a new RFC obsoleting 7366, just updating  
the text, if the errata text would be too extensive.

> always serious about it. I honestly don't know.

The possible issue is that a version might get widely deployed before a  
specific issue is properly documented; just as examples of such issues are  
version and extension intolerance, and personally, the SNI implementation  
I originally wrote for Opera caused it to crash when actually encountering  
a server responding to the SNI extension. Might not happen in this case,  
since I am not aware of any actually deployed servers or clients.

-- 
Sincerely,
Yngve N. Pettersen

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Sun, 02 Nov 2014 00:30:58 +0100

(Cutting a lot of details where we agree about the important points, to get to
the "what should be done now" part.)

> after it was used for something.
100% agreed, I think for me the use of the same name for two different values
was the root cause of the confusion. How about combining Peter's above paragraph
with my proposed rewriting of the MAC calculation as:

           In TLS [2] notation, the MAC calculation for TLS 1.0 without
   the explicit Initialization Vector (IV) is:

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       length of (ENC(content + padding + padding_length)) +
       ENC(content + padding + padding_length));

   and for TLS 1.1 and greater with an explicit IV is:

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       length of (IV + ENC(content + padding + padding_length)) +
       IV +
       ENC(content + padding + padding_length));

    where the length is encoded as two bytes in the usual way.

It's admittedly not he most elegant, but at least it's clear and unambiguous,
which is probably more important than elegance for an erratum.

> the text, if the errata text would be too extensive.
Ok, it never hurts to consider possibilities. I'm not experienced enough with
the standards process to have an opinion on this one. I think it's clear that we
want an erratum soon regardless of what is or isn't deemed necessary later.

>> I'd expect any half-serious implementer to test interop with at least one
>> other implementation before releasing. Unfortunately, experience proves
>> people are not always serious about it. I honestly don't know.
>
Yes, that sort of thing is unfortunately can't be ruled out. As above, I
honestly don't know what the best approach is, but it probably starts with an
erratum, and hopefully also ends with the erratum!

Manuel.

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Sun, 02 Nov 2014 00:36:40 +0100

On Sun, 02 Nov 2014 00:30:58 +0100, Manuel Pégourié-Gonnard  
<[email-masked]> wrote:

>>> [1]  
>>> http://mailarchive.ietf.org/arch/msg/tls/3NOHlIUShLo9AAzXx4t2u7QV8Sw
>>>
>>>   encoded in the TLSCiphertext record is 'length' while the length  
>>> value
>>> used

That looks fairly OK to me.

A possible tweak one could add, is to define

     encrypted_content = ENC(content + padding + padding_length)

and use that in the formula instead.

-- 
Sincerely,
Yngve N. Pettersen

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Sun, 02 Nov 2014 00:45:18 +0100

> That looks fairly OK to me.
Cool, we're converging.

> and use that in the formula instead.
As Peter pointed out after the first version of my proposal, we need two
versions: one for TLS 1.0 (no IV) and one for higher versions, to point out the
IV is included.

Manuel.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 2 Nov 2014 02:32:42 -0500 (EST)

----- Original Message -----
> ward compatibility with SSLv3 "03 00" is forbidden at the record level.

That's pretty pointless and harms interoperability. With that you are not 
forbidding SSL 3.0, but all implementations which use 3.0 in the record 
version for client hello. That was widely used as a mitigation in the past
for other broken servers that only accepted SSL 3.0 version field.

In any case, the version in TLS record indicates the record format, not the 
negotiated version, which is present in the client hello handshake packet.

The last two paragraphs of http://tools.ietf.org/html/rfc5246#appendix-E.1
make that clear: "Thus, TLS servers compliant with this specification MUST accept
any value {03,XX} as the record layer version number for ClientHello.".

regards,
Nikos

---

From: "Christian Kahlo" <[email-masked]>
Date: Sun, 2 Nov 2014 22:32:20 +0100

> That's pretty pointless and harms interoperability. With that you are
> not forbidding SSL 3.0, but all implementations which use 3.0 in the
> record version for client hello. That was widely used as a mitigation
> in the past for other broken servers that only accepted SSL 3.0 version
> field.

In fact there are very few and rare clients using "03 00" in the record
version field. The only clients I know of are some custom probers.

> In any case, the version in TLS record indicates the record format, not
> the negotiated version, which is present in the client hello handshake
> packet.
> 
> make that clear: "Thus, TLS servers compliant with this specification
> MUST accept any value {03,XX} as the record layer version number for
> ClientHello.".

OK. Fixed. Checked In. Deployed.

---

From: "Christian Kahlo" <[email-masked]>
Date: Sun, 2 Nov 2014 22:53:14 +0100

> > The last two paragraphs of
> http://tools.ietf.org/html/rfc5246#appendix-
> > E.1

By the way this is an operational system. The server is PFS-only with
ECDSA_RSA activated. RC4 and Camellia are not supported and 3DES is
deactivated. TLS1.0 is supported but not enabled.

---

From: [email-masked] (Martin Rex)
Date: Mon, 3 Nov 2014 18:11:18 +0100 (CET)

> deactivated. TLS1.0 is supported but not enabled.

None of this matters.  Server that reject the Handshake because the
initial ClientHello on a new connection arrived in a TLS Record with
an outer { 0x03, 0x00 } protocol_version is *ACTIVELY* hurting
interop in an extremely serious fashion, and server misbehaviour like
this is the reason why the "downgrade dance" heuristics that current
browsers are performing.

The original TLS protocol provides a means for protected negotiation of
protocol features, and a regular/generic client that doesn't contain
any complex reconnect fallback ("downgrade dance") logic at the application
level will be using { 0x03, 0x00 } in the Record Layer for the initial
ClientHello.  This choice will provide out-of-the-box connectivity to
a few remaining old SSLv3-only servers, while simultaneously ensuring
that only newer protocol versions will get used with servers that
support newer TLS protocol versions.

A reason why even TLS clients that do not want to talk SSLv3,
would sensibly be using { 0x03, 0x00 } here, is that they can normally
expect to get an SSL alert in return if the server understands the
SSL/TLS record format.

-Martin

---

From: "Christian Kahlo" <[email-masked]>
Date: Mon, 3 Nov 2014 19:03:48 +0100

> > > > make that clear: "Thus, TLS servers compliant with this
> > > > specification MUST accept any value {03,XX} as the record layer
> > > > version number for ClientHello.".
> > >
> initial ClientHello on a new connection arrived in a TLS Record with an
> outer { 0x03, 0x00 } protocol_version is *ACTIVELY* hurting interop in
> an extremely serious fashion, and server misbehaviour like this is the
> reason why the "downgrade dance" heuristics that current browsers are
> performing.

It seems we simply missed that when adding TLS1.2. TLS1.1, the original
implementation target, http://tools.ietf.org/html/rfc4346#appendix-E is
less strict about this and could be interpreted in a different way. The
"MUST accept {03,XX}" section is completely missing there. [1]

> any complex reconnect fallback ("downgrade dance") logic at the
> application level will be using { 0x03, 0x00 } in the Record Layer for
> the initial ClientHello.  This choice will provide out-of-the-box
> connectivity to a few remaining old SSLv3-only servers, while
> simultaneously ensuring that only newer protocol versions will get used
> with servers that support newer TLS protocol versions.
 
Already understood and fixed as stated yesterday.
 
> A reason why even TLS clients that do not want to talk SSLv3, would
> sensibly be using { 0x03, 0x00 } here, is that they can normally expect
> to get an SSL alert in return if the server understands the SSL/TLS
> record format.

Sounds reasonable.
But this server was not meant to be a "web server" serving contents
for a wide range of browsers and thus SSL/TLS client libraries.
Within the last 4 years we never experienced any trouble with OpenSSL
(mostly patched versions for RSA-PSK support), Bouncycastle, JSSE and
completely custom TLS stacks you even don't know of and probably never
will. I had not seen GnuTLS to be used in this somewhat closed infra-
structure. Once upon a time we did some tests with V2.4.2 and I had
never used it again since these tests.

Thanks for the hint, it's now compliant to RFC5246. Time to calm down.

Cheers,
Christian

1:"Similarly, a TLS 1.1  server that wishes to interoperate with TLS 1.0
   or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages and
   respond with a SSL 3.0 server hello if an SSL 3.0 client hello with a
   version field of {3, 0} is received, denoting that this client does
   not support TLS.  Similarly, if a SSL 3.0 or TLS 1.0 hello with a
   version field of {3, 1} is received, the server SHOULD respond with a
   TLS 1.0 hello with a version field of {3, 1}."

   It simply never wished to do so and was compliant with RFC 4346 and
   RFC 4279 (the original target required by the German Office for
   Information Security).

---

From: Martin Thomson <[email-masked]>
Date: Mon, 3 Nov 2014 11:31:54 -0800

> mostly means rejecting clients that want to interoperate with old servers.

Yes, our current guidance is that servers SHOULD accept these
sessions, as long as they don't negotiate SSLv3. [1]

[1] https://github.com/unicorn-wg/sslv3-diediedie

---

From: [email-masked] (Martin Rex)
Date: Thu, 6 Nov 2014 00:58:23 +0100 (CET)

Yngve,

> (the ones that are causing concern for version rollback recovery) will be  

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.

>         case block_encrypted: TLS_Block_Encrypted_data;

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

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Thu, 06 Nov 2014 01:16:11 +0100

> of rfc7366 is a failure (beyond fixing through the errata process).
Really? Could you please elaborate on why you think the proposed fixes in [1]
(undoubling the doubled paragraph) and [2] are not correct fixes suitable for an
erratum?

[1] http://mailarchive.ietf.org/arch/msg/tls/3NOHlIUShLo9AAzXx4t2u7QV8Sw
[2] http://mailarchive.ietf.org/arch/msg/tls/zYBKe9L9n3tNZ_SBWn77ubLzNPs

Manuel.

---

From: [email-masked] (Martin Rex)
Date: Thu, 6 Nov 2014 01:36:04 +0100 (CET)

Manuel Pégourié-Gonnard wrote:
[ Charset windows-1252 unsupported, converting... ]

>> length field of the redefined rfc7366 TLSCiphertext and frobbing

It would be like publishing

   2+2 = 5

and then posting an errata that says

   ...provided that the first instance of "2" is sufficiently close to "3".

I've seen a number of discussion where longterm IETF folks (including ADs)
were significantly opposed to adding a clarifying sentence through errata
(which indicates that a sender will have to include a certain element
in a list of elements or one specific scenario will fail interop),

and among the reasons for why such a one-line clarification would
go beyond the purpose of the errata process were:
  (1) not all implementors with read erratas (or notice that an errata exists)
  (2) this is a new requirement and changes the protocol

While (1) is certainly true, I believe that it didn't apply on the
specific errata.  (2) certainly was a bogus claim, because it did
not change any requirements at all (it's just one of several implied
requirements), and the purpose of the clarification was to make it
known to implementors ahead of time _why_ they will face interop
failures in specific scenarios if they didn't recognize or understand
this implied requirement.

The problem with rfc7366 is that what the published specification describes
is not what folks have (or want to implement), and an implementation of
what rfc7366 truely specifies will be entirely non-interoperable with
what folks want and do.  And rfc7366 is even more misleading about
the _real_ TLS protocol PDUs than the original SSLv3 and TLS documents.

-Martin

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Thu, 06 Nov 2014 01:52:07 +0100

>    ...provided that the first instance of "2" is sufficiently close to "3".
In my view, the proposed errata is closer to actually replacing the first 2 with
a 3 (that's [1]) and then adding a paragraph pointing out the difference (that's
[2]).

Just to be sure: is your point that the proposed text for the errata is not
clear enough, or that you think this is "too big" for an erratum? If it's the
later, as I said before, I lack experience with the IETF process to have a
serious opinion on that.

I just hope we soon have a solid basis to continue writing implementations and
deploying them, and I leave to more knowledgeable people the question of what's
the best way to achieve that goal (errata, new RFC, etc.)

Manuel.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 06 Nov 2014 10:04:02 +0100

>    ...provided that the first instance of "2" is sufficiently close to "3".

No point in arguing about that. No text is perfect. Given that this
document is the only way to fix the issues with the cbc ciphersuites for
tls >= 1.1, it must be corrected one way or another. That is because it
is the only way to provide reasonable security for implementations which
do TLS 1.1 and don't have any other choice (such as the GCM
ciphersuites). If you think additional text is required please propose
it.

regards,
Nikos