Re: [TLS] Certificate URL extension in draft-ietf-tls-rfc4366-bis-02

[Mike <mike-list at pobox.com>]

> The issue is whether to make the hash mandatory in the client
> certificate URL extension.  Without the hash it presents some
> vulnerabilities in that the certificate can be replaced.  With the hash
> it will cause difficulty for clients that are issued a new certificate
> that is populated in the repository before they have a chance to
> retrieve it.  It seems that on the list there was some very rough
> consensus to make the hash mandatory.  
>
> In order to resolve this issue I propose that we make the hash mandatory
> for this extension.  If this causes an operational problem in some
> environments then a new extension can be defined that has an optional or
> no hash.  

It doesn't sit well with me that you have URLAndOptionalHash, and then say
that the hash is not optional.  Plus it's been optional for more than two
years, so changing it now is not backward compatible.

Another observation is that if a client determines the certificate hash by
fetching the certificate and calculating the hash of what it receives, you
have not solved the substitution problem -- in fact that makes it worse
since the server will be more confident in the certificate than if no hash
was sent -- the client needs to be configured with the hash.  (This means
that this extension does not lessen configurability requirements; it only
allows a client to save a little bit on memory.)

In addition, it seems you don't want to be stuck with SHA-1 anyway, so
perhaps it would be best to deprecate the current CertificateURL and create
a new extension with hash agility added:

    struct {
        opaque        url<1..2^16-1>;
        HashAlgorithm algorithm;
        opaque        hash<1..2^8-1>;
    } URLAndHash;

Mike
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls