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

[Manuel Pégourié-Gonnard <[e-mail]>]

On 06/11/2014 01:36, Martin Rex wrote:
> 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".
>
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.