Re: [TLS] Collisions (Re: Consensus Call: FNV vs SHA1)

[Marsh Ray <[e-mail]>]

On 5/11/2010 4:05 PM, Stefan Santesson wrote:
> On 10-05-12 12:55 AM, "Marsh Ray" <[e-mail]> wrote:
> 
>>
>>> On the other hand, I would not object to include a requirement that data
>>> should/must only be cached from a successful handshake where the server is
>>> successfully authenticated. That should remove any residue of this issue.
>>
>> If "successfully authenticated" is only fully determined sometime after
>> returning application code, does that mean that this extension should
>> never come enabled by default for a TLS library?
> 
> There is a difference between passing path validation, which is done by the
> crypto library, and deciding if the certificate subject is an appropriate
> entity, which is done by the application.
> 
> In this case I think it is enough that the certificate pass path validation
> to a trusted root.

Usually something like that is either critical to the security of the
protocol (and thus needs a cryptographic-strength guarantee) or it's not
(in which case whatever is fine).

I don't see what cert validation directly solves here. After all, the
bad guy can get certs signed, too. Why would it matter if the CN is
different if the CN isn't checked?

In the certificate, the "to-be-signed" tbsCertificate subfield is the
only part directly covered by the signature. Is it possible that an
attacker can modify unused bytes, or append any additional junk in the
part that's not signed? For example, it looks like an RSA signature (RFC
2313 PKCS #1 v 1.5) might admit some nul prefix bytes (it's an integer).
It wouldn't take many modifiable bytes to be able to engineer an
arbitrary FNV-1a value.

Of course the trusted_cas type remains trivially collidable.

- Marsh