Re: [TLS] Consensus call for certificate URL extension
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] Consensus call for certificate URL extension
Joseph Salowey wrote:
>
> We need to close this open issue. I think there are two basic options
> that address the security issues that have been raised:
>
> A) Deprecate the current extension and create a similar new extension
> with the hash mandatory.
>
> B) Make the hash mandatory in the current extension. This should not
> cause deployment problems because there are no known deployments that
> make the hash optional.
>
> In either case, we can include hash agility as described in
> http://trac.tools.ietf.org/wg/tls/trac/ticket/46. If there is support in
> the working group for the use case where the certificate is updated
> offline then we can possibly work on a new extension in a new document
> that incorporates ideas expressed on the list.
>
> Please express you preference on the list for one of these options by
> 10/6/2008.
My position is
C) leave as is, with hash optional
(and recommend against implementing or deprecating this TLS extension)
Personally, I don't like this extension, because it creates a lot
of additional complexity and serious vulnerabilities for the server
(DoS of the Server being the mildest aspect).
Why do I NOT like making the hash mandatory?
If a client is able to provide the hash matching the certificate
found under that URL, it should equally be able to include the
certificate itself in the handshake instead of the URL and remove
all problems and vulnerabilities of this extension entirely.
I do NOT want to see that extension being pushed any further,
and making one with the hash mandatory would make it an encoragement.
-Martin
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.