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

[[e-mail] (Martin Rex)]

Manuel Pégourié-Gonnard wrote:
[ Charset windows-1252 unsupported, converting... ]
> On 06/11/2014 00:58, Martin Rex wrote:
> > I agree with many parts of your root cause analysis why the content
> > 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


I had included the rationale in the mail from which you quote above:

>>
>> 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.

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