Re: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Additionx

[Eric Rescorla <[e-mail]>]

This message does not appear to provide anything new, so in the interest
of not going around in circles, I'll forego a detailed response.

-Ekr


On Wed, Mar 9, 2011 at 8:38 AM, Martin Rex <[e-mail]> wrote:
> Eric Rescorla wrote:
>>
>> > Yes, I'm aware what TLSv1.2 says.
>>
>> Then why did you call it a hard limit above? It's not.
>
> How do two independent implementations of rfc-5246 use finished
> messages truncated to no less than 128 bits with the cipher suites
>
>   TLS_RSA_WITH_AES_256_CBC_SHA256       { 0x00, 0x3D }
>   TLS_DHE_DSS_WITH_AES_256_CBC_SHA256   { 0x00, 0x6A }
>   TLS_DHE_RSA_WITH_AES_256_CBC_SHA256   { 0x00, 0x6B }
>
> If the answer is "they can not", then this is what I
> consider a "hard limit".
>
>>
>> > But I'm much more aware of
>> > the complete lack of guidance (a pointer to rfc-2104 section 5
>> > would have been sufficient).
>>
>> As both Hovav and I have explained to you,
>> we don't think that guidance is relevant here.
>
> I hear you saying "nobody needs more than 640KB^W96-bit security for HMACs".
> The IPSEC fanciers seem to be disagreeing with you by a margin.
>
> From Hovav I only know what he wrote, not what he thinks:
>
>>
>> Any truncation of HMAC-SHA384 -- the PRF at hand -- to fewer than 384/2
>> = 192 bits means you are in the former regime rather than the latter.
>>  That's fine, provided k-bit security is sufficient, as 96-bit security is
>> here; it just means that having built HMAC using SHA384 was overkill, which
>> it of course was.
>
> The existance and contents of rfc4868 indicates that not everyone
> in the IETF might be agreeing to your opinion that truncation of
> HMACs to 96 is sufficient security for everyone and everything.
>
>
> For me, a TLS cipher suite spec that wants to provider stronger
> security than what is available in the base spec and therefore redefines
> the PRF with a hash that has a longer output value, the truncation of
> the verify_data in the finished message _is_ relevant.
>
> There is another TLS documents (TLS extensions) that _correctly_
> points to [HMAC]/[RFC2104] Section 5 for the details of the HMAC
> truncation:
>
>  http://tools.ietf.org/html/rfc6066#section-7
> and
>  http://tools.ietf.org/html/rfc4366#section-3.5
>
> say
>
>                                                 Subsequently during the
>   session, clients and servers MUST use truncated HMACs, calculated as
>   specified in [HMAC].
>
>
> So it is somewhat unlikely that implementors really miss the truncation
> size guidance in that referenced section 5 of [HMAC]:
>
>  http://tools.ietf.org/html/rfc2104#section-5
>
>
> The section where TLSv1.2 does truncation (on the verify_data):
>
>  http://tools.ietf.org/html/rfc5246#section-7.4.9
>
> lacks this pointer to rfc-2104 section 5.
>
> I consider this a defect of rfc-5246 with the result as seen
> in the spec named in the subject of this thread.
>
>
> Having just re-read 7.4.9 -- where does draft-kanno-tls-camellia-00
> actually comply to this MUST of rfc-5246?
>
>                   Any cipher suite which defines a different PRF MUST
>      also define the Hash to use in the Finished computation.
>
>
> A grep -i -e "finish" -e "verify" does not find a match.
>
>
>
> -Martin
>
>
>
>>
>>
>> > Alternatively, if they favour your attitude that actually
>> > SHA-1 would have been good enough, and SHA-256 is plenty,
>> > they should remove all the -SHA384 ciphersuites from the
>> > document.
>>
>> Yes, that would be fine with me.
>>
>>
>> >> > TLSv1.2 was supposed to provide a framework that can deliver TLS
>> >> > with a strength >128=bits of security.  But it failed to deliver
>> >> > this by (1) not adjusting the truncation of the finished messages
>> >> > and (2) not documenting that the truncation of the finished messages
>> >> > MUST be done along with the use of stronger ciphers, stronger hashes
>> >> > and larger key lengths in order to actually obtain a balanced
>> >> > security of the desired higher strength.
>> >>
>> >> Well, as I've said during this thread, I believe your understanding of what
>> >> "security level" means in this context is wrong. I.e., a 128-bit security
>> >> level against offline attack is very different than a 2^{-128} chance of
>> >> successful guessing exactly once on each connection. However, TLS 1.2
>> >> does in fact have the flexibility you are requesting.
>> >
>> > TLSv1.2 should have used that flexibility itself for a SHA-256 PRF,
>> > and should have provided a pointer to rfc-2104 section 5 for selecting
>> > an adequate truncation size for TLS cipher suite specs that use this
>> > flexibility.
>>
>> > What seems to have happened is that although there are cipher suite
>> > specs that redefine the PRF, they fail to address the truncation
>> > because TLSv1.2 fails to address the truncation ("bad precedent").
>>
>> As stated above, I disagree with this claim. However, as it's moot
>> now, I don't think
>> there's a lot of point in discussing it further.
>>
>> -Ekr
>>
>>
>
>