Re: [TLS] Next steps for Client Certificate URL

[Nelson B Bolyard <nelson@xxxxxxxxxxx>]

Nikos Mavrogiannopoulos wrote, On 2008-03-29 03:15:
> Nelson B Bolyard wrote:
>> Pasi.Eronen@xxxxxxxxx wrote, On 2008-03-28 07:13:
>>
>>> Given this, would everyone be OK with updating the existing
>>> client_certificate_url extension so that including the hash is
>>> mandatory (client MUST send, server MUST NOT accept without hash)?
>>> This behavior would be independent of the negotiated TLS version.
>> I'm trying to understand the attack against which this hash is going
>> to protect, that is not already adequately protected without it.
>> Can someone outline that attack here?
> 
> Usually even if you do not have an attack at hand, it might be good to 
> prove that a modification to a security protocol makes it no less 
> secure. By adding the hash (and considering it ideal) it is not hard to 
> prove that the modified scheme is as strong as by sending the 
> certificate itself.

Given two protocols of equivalent security, the one with less overhead is
preferable in the marketplace.  If the best thing that can be said about
the addition of the hash is that it makes the protocol no less secure,
that is hardly a compelling reason to make it mandatory, as Pasi proposed.

In answer to Pasi's question, quoted above, I object to making purely
redundant processing required for client cert URLs in TLS.  It suffices
to be available. If a need for it arises, then it can be used.

_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls