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

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 24 Jul 2008 08:13:49 -0700

I would like to get this document ready for working group last call.  I
think there is only one major outstanding issue on the certificate URL
extension.  

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.  

Please send comments on this resolution to the list.  

Joe
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 24 Jul 2008 09:06:05 -0700

At Thu, 24 Jul 2008 08:13:49 -0700,
> environments then a new extension can be defined that has an optional or

I agree with this plan.

-Ekr

---

From: Mike <[email-masked]>
Date: Thu, 24 Jul 2008 10:10:32 -0700

> environments then a new extension can be defined that has an optional or

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

---

From: Martin Rex <[email-masked]>
Date: Thu, 24 Jul 2008 19:25:19 +0200 (MEST)

> years, so changing it now is not backward compatible.

In principle, I agree with Mike.  If it has been optional, it should
remain that way.  Having it optional doesn't affect clients which
want to send it.  If an attacker strips the hash with an MITM,
it should cause the finished MACs to fail.

We already discussed the sevever security problems connected to
the client cert URL extensions, and IMHO, there should be text
in the spec that requires server implementations to have this
feature disabled by default and recommends server operaters to
NEVER EVER enable this feature unless they're really positively
sure that they can not live without it and that they're willing
to take the chanced by allowing everyone and his dog to coerce
their SSL servers into arbitrary HTTP downloads.

-Martin

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 24 Jul 2008 16:04:11 -0700

Mike wrote, quoting Joseph Salowey,

> years, so changing it now is not backward compatible.

Right.  If a new extension must be defined, the onus to do so should be on
those who wish to change the existing extension.  If some folks want a new
extension in which the hash is not optional, and/or the hash algorithm
is flexible (as Mike suggests), then those folks should define the new
extension with those properties.

The people who want to keep the existing extension, as it has been defined
for years, should not need to define a new extension just to preserve the
existing one's semantics.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 24 Jul 2008 16:52:21 -0700

At Thu, 24 Jul 2008 16:04:11 -0700,
> existing one's semantics.

So, is there anyone actually using the extension without digests? If so,
now is the time to speak up. If not, then the "we want to keep it as-is"
tends to lose some of its force.

-Ekr

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 24 Jul 2008 21:56:31 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mike
> Sent: Thursday, July 24, 2008 10:11 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [TLS] Certificate URL extension in 
> draft-ietf-tls-rfc4366-bis-02
> 
> > 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;
> 
[Joe] Issue 46 (http://trac.tools.ietf.org/wg/tls/trac/ticket/46)
suggests a mechanism for hash agility that provides some degree of
backward compatibility.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 25 Jul 2008 21:11:44 +0300

Mike wrote:

> was sent -- the client needs to be configured with the hash. 

I don't think this is an issue. The client can verify if the certificate
is issued to him or not. Can't he?

> > If this causes an operational problem in some

I would be opposed to any extension that allows retrieval of a
certificate without any verification included in the handshake. If
something like this occurs the TLS handshake weaker than in the case of
including the certificate in it.

For some extension like this to be added one has to prove that it
doesn't affect the overall protocol security.

regards,
Nikos

---

From: Mike <[email-masked]>
Date: Fri, 25 Jul 2008 12:10:47 -0700

> is issued to him or not. Can't he?

Well if you want my full thoughts on this, then here goes.  The hash of
the certificate is the wrong piece of information to use for validation
since it can change over time as new certificates are issued.  What is
really needed is something static identifying the subject, either the
subject DN or an alternative name.  I guess a DER-encoded GeneralNames
would be the most flexible, but that is certainly not TLS-ish.  If the
client sent this identity information to the server instead, then it
could check for a match itself, eliminating the problem of a certificate
being reissued prior to the client retrieving it and calculating the
hash.  The client also becomes simpler since it wouldn't ever have to
retrieve/process its own certificate.

Mike

---

From: "Nikos Mavrogiannopoulos" <[email-masked]>
Date: Fri, 25 Jul 2008 22:35:13 +0300

> retrieve/process its own certificate.

This is a very nice alternative. It might be appropriate to include
the key parameters to the hash as well though.

regards,
Nikos

---

From: Martin Rex <[email-masked]>
Date: Fri, 25 Jul 2008 22:10:59 +0200 (MEST)

> retrieve/process its own certificate.

Sending/including the Subject DName would be a "cleaner" approach,
because it does what should be done:
the client _should_ assert his identity when attempting an authentication
instead of playing the game "I don't know who I am, but here's the name
of someone who knows".

However, the Subject DName will likely not work with End Entity
certs that have an empty Subject DN (a non-empty subjectAltName instead).

-Martin