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

[Martin Rex <[e-mail]>]

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