Subject: [TLS] TLS document status update

From: <[email-masked]>
Date: Tue, 29 Apr 2008 15:18:31 +0300

Here's a short status update on TLS WG documents:

draft-ietf-tls-rfc4346-bis

   This is in RFC Editor final AUTH48 stage, so it should be out 
   as RFC 5246 soon.

draft-ietf-tls-rsa-aes-gcm: 

   The draft went through WGLC, and Joe posted version -03 which
   seems to address the WGLC comments.  Unless there are
   objections, this will be sent to AD evaluation once the chairs
   get the Document Shepherd Write-Up written.

draft-ietf-tls-ecc-new-mac

   The draft also went through WGLC; version -05 seems to address
   the WGLC comments, but has some editorial nits. Once Eric 
   submits version -06, this will be sent to AD evaluation.

draft-ietf-tls-rfc4366-bis
   
   The only technical issue is whether (and how) to mandate
   including the hash in certificate_url message. Everyone except
   Nelson has supported making the hash mandatory.

   If I understand Nelson's view correctly, he considers the
   original use case for omitting the hash (CA automatically posts
   renewed certificates at certain URL, and the client does not
   necessarily have a copy of the latest cert) more important than
   the (rather theoretical) attacks that omitting the hash might
   have. Nelson, would this be a fair summary of your objection?  

draft-ietf-tls-extractor

   The draft is basically ready for WGLC -- hopefully starts soon.
   
draft-ietf-tls-des-idea

   The draft is basically ready for WGLC, but has been waiting
   until the other documents progress.

draft-ietf-tls-ecdhe-psk

   The draft is basically ready for WGLC, but has been waiting
   until the other documents progress.

Best regards,
Pasi
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Nelson B Bolyard <[email-masked]>
Date: Tue, 29 Apr 2008 08:14:09 -0700

>    have. Nelson, would this be a fair summary of your objection?  

Yes.  The client doesn't necessarily have ANY copy of its own cert.
The proposed requirement that the client MUST include a hash of the
cert it does not have presents a new problem for such implementations.

White-listing of hosts from which the server is willing to fetch those
client cert URLs effectively solves the other problems without
necessitating any mandatory hashes.

Thanks for your document status summary.

/Nelson

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Apr 2008 08:26:18 -0700

At Tue, 29 Apr 2008 08:14:09 -0700,
> cert it does not have presents a new problem for such implementations.

Given that the client is about to ask the server to download a copy,
I don't really see why there's a problem with the client getting
a copy first and sending the hash over.

> necessitating any mandatory hashes.

No, it doen't solve the substitution attack.

-Ekr

---

From: Mike <[email-masked]>
Date: Tue, 29 Apr 2008 09:24:24 -0700

>> The client doesn't necessarily have ANY copy of its own cert.

There is the problem of the client knowing when its certificate is
updated and that it should retrieve a new copy to recalculate the
hash.  It could keep track of its own validity period, but that
complicates things, and wouldn't work if the CA decides to reissue
a certificate early.

> No, it doen't solve the substitution attack.

But how could the substitution attack even succeed?  You would need
to create a valid CA signature on the replacement certificate, which
should not be possible.

Mike

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 29 Apr 2008 23:11:55 +0300

> to create a valid CA signature on the replacement certificate, which

The fact that you cannot present an attack doesn't mean there is no
attack, or that a combination of such weaknesses might be exploitable.
The TLS handshake finished message hashes protect the certificate by
including it. If the certificate is not exchanged during the handshake
then this protection is no longer available.

So:
1. If this protection is not really required, then it can also be
removed it from the original TLS handshake.

2. If this protection is required, then it should be present in the
abbreviated handshake with the certificate URL (in the form of
certificate hash), so equivalent security is offered by equivalent
ciphersuites.

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Apr 2008 13:20:41 -0700

At Tue, 29 Apr 2008 09:24:24 -0700,
> complicates things, and wouldn't work if the CA decides to reissue

Polling occasionally hardly seems like an insuperable barrier.

> to create a valid CA signature on the replacement certificate, which

Why not? All you need is a CA which doesn't require technical
Proof of Possession of the private key.

-Ekr

---

From: Mike <[email-masked]>
Date: Tue, 29 Apr 2008 13:42:05 -0700

> Proof of Possession of the private key.

If you can't trust your own CA, then by all means send the hash.

The discussion is about whether a client MUST send the hash.  So
far it seems like SHOULD is the most appropriate, with relevant
comments in Security Considerations.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Apr 2008 14:06:48 -0700

At Tue, 29 Apr 2008 13:42:05 -0700,
> If you can't trust your own CA, then by all means send the hash.

This is not about trusting your own CA, because a CA which issues
certificates without requiring PoP is not acting in an untrustworthy
fashion.

To recap, the attack looks like this:

1. Alice gets a certificate with key pair K_pub, K_priv.
2. The attacker gets his own certificate with K_pub, K_priv
   under his own name.
3. Alice connects to the server and offers to authenticate
   using certificate_url.
4. The attacker intercepts the server's connection to the
   URL provided by Alice and substitutes his own certificate.
5. The server now thinks that any data sent by Alice was
   actually sent by the attacker.

So, first of all, whatever CA the attacker used has not done
anything wrong. Second, the CA can be totally different from
the client. Third, the client has no way of knowing what
policies the CAs trusted by the server enforce.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Apr 2008 00:16:44 +0200 (MEST)

The "vulnerabilities" in the client-cert-URL extension without
certificate hash are IMHO somewhat subtle.  It definitely not
a regular MITM type of attack.

The thing that *I* don't like is the following:

IMHO, the client should always consciously assert an identity
when performing an authentication.  The private key & certificate
are only a means to prove ownership of that identity.
 Normally, this is done by including a specific certificate
in the authentication that contains a binding of a public
key to an identity.

The server is, in general, going to grant access based on the
identity (or authorizations bound to the identity),
and *NOT* based on the public key -- otherwise the use
of a certificate instead of a naked public key would be
a huge wasted effort.

If the client does not assert an identity during authentication,
but instead passes an URL, then it is no longer asserting
the identity (in a protected fashion).  Personally, I consider
that a (security) problem.

If an attacker could get a certificate issued with the clients
public key and someone elses identity, then he might have a means
to cause trouble for the client by subtituting the certificate
(when the server tries to download it).

I would not feel comfortable with an authentication protocol
where only a password is sent, and the server is supposed to
figure out by himself to which account the authentication
should be mapped.

And maybe you could abuse this to have the server check
whether someone('s certificate)  someones account exists,
depending on the servers error message...

-Martin

---

From: Mike <[email-masked]>
Date: Tue, 29 Apr 2008 17:16:30 -0700

>    actually sent by the attacker.

But won't the CertificateVerify message fail since the attacker
has a different private key than Alice?

In any case, maybe the data that needs to be sent is not the
hash of the certificate, but rather the identity the client
wants to authenticate as.  This could be the subject DN, or
SAN from the certificate.  An advantage of using that is that
it is invariant even as the actual certificate is periodically
reissued.

Mike

---

From: Mike <[email-masked]>
Date: Tue, 29 Apr 2008 17:25:02 -0700

> Polling occasionally hardly seems like an insuperable barrier.

Another problem is if the client merely polls the URL to obtain the
certificate to calculate the hash without verifying that the cert.
is correct.  And how can it know if the certificate is correct w/o
having its own copy?  This extension could just be a big can of
worms.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Apr 2008 17:37:22 -0700

At Tue, 29 Apr 2008 17:16:30 -0700,
> has a different private key than Alice?

No, because the attacker is presenting a certificate with
Alice's public key and Alice is doing the signing. Remember
that the key to the attack is that the attacker is able to
get a cert for a name of his choice but with Alice's public
key.

> it is invariant even as the actual certificate is periodically

Perhaps yes, but that would require an actual change to the syntax of
the protocol, whereas this is just a new requirement to use the
existing syntax.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Apr 2008 17:38:46 -0700

At Tue, 29 Apr 2008 17:25:02 -0700,
Mike wrote:
> having its own copy?

Huh?

The client has been configured with the URL for the CA. It can also
be configured with the expected DN and the CA's public key.

-Ekr

---

From: Nelson B Bolyard <[email-masked]>
Date: Tue, 29 Apr 2008 20:54:52 -0700

Eric Rescorla wrote, On 2008-04-29 17:37 PDT:
> [...] the attacker is presenting a certificate with

I call that CA malfeasance, having issued a cert without proof of
key possession.  Perhaps a server that trusts such a CA gets what it
deserves.

Given the usual assumptions of the improbability of key collisions, upon
which digital signature systems depend, I claim that in the absence of
- CA malfeasance,
- CA collusion,
- CA key compromise,
- EE (victim) key compromise,
- TLS server malfeasance (failing to verify signature on cert, or
  client's certificate verify message), and
- server application malfeasance (failure to verify authorization of
  the verified identity),
the worst the attacker can do is to substitute a certificate that causes
a denial of service.

In the unlikely event that the attacker is able to find a valid cert
with the same public key as the victim's, issued by one of the CAs trusted
by the server for client auth, it is very unlikely that the identity on
that cert is one of the attacker's choosing or under the control or even
influence of the attacker.  The probability that the attacker finds a
key collision for a valid cert with an identity that he controls (or from
which he directly benefits) is essentially the same as (equivalent to?) the
probability that he possesses or controls the victim's private key, which is
effectively EE key compromise, which I excluded above.  Substitution of a
"random" client cert (whose identity is not under the attacker's control or
to his benefit) is likely to result in no more than denial of service, for
the reasons stated.

But denial of service can be accomplished in many other more trivial ways.
The hash doesn't protect against it.

>> it is invariant even as the actual certificate is periodically

Yes, I could accept that, too.  That appears to address the concern that
Eric (and others) have stated without imposing unnecessary limitations
and difficulties.  I agree with Martin's point that the client needs to
assert an identity, which the signature merely verifies.

A hash protects against some of the conditions I excluded above, but so
does an identity assertion.

> the protocol, whereas this is just a new requirement to use the

Yes, but perhaps it's worthy of undertaking to make that change.
Use of the extension could require either a hash or a GeneralName.

/Nelson

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Apr 2008 21:57:04 -0700

At Tue, 29 Apr 2008 20:54:52 -0700,
> key possession.  Perhaps a server that trusts such a CA gets what it

Then I encourage you to take that up with PKIX, since it seems
clear to me that this is explicitly allowed (RFC 3280 S 3.1.):

   This confidence is obtained through the use of public key
   certificates, which are data structures that bind public key values
   to subjects.  The binding is asserted by having a trusted CA
   digitally sign each certificate.  The CA may base this assertion upon
   technical means (a.k.a., proof of possession through a challenge-
   response protocol), presentation of the private key, or on an
   assertion by the subject.  A certificate has a limited valid lifetime

> The hash doesn't protect against it.

The above material seems to be premised on the assumption that CAs
who issue certificates without PoP are acting improperly, but as
indicated above, I don't think that's at all clear, so I don't
really subscribe to the conclusion either.

> Use of the extension could require either a hash or a GeneralName.

Well, this would require creating an entirely new extension,
since the client_certificate_url extension has no way of 
indicating whether hash (or anything else) will be indicated
in the CertificateURL message, so the client can't safely
provide a GeneralName value without potentially sending
something the server can't handle. Not saying you shouldn't
propose such an extension, but I don't see how that's an
argument against requiring hash with this one.

-Ekr

---

From: <[email-masked]>
Date: Wed, 30 Apr 2008 11:27:39 +0300

> to create a valid CA signature on the replacement certificate, which

This has been explained couple of times earlier, but let me recap
one scenario:

Assume that the client has several certificates (all of which are
properly issued by valid CAs) that contain the same public key, but
different subject names.

For example, one of the subject names could identify the user as an
employee of Example Inc; another name could be his personal identity;
third one might be an administrator/superuser role; etc.

(In this example, nobody's keys have been compromised, all CAs are
behaving exactly as they should, proof-of-possession is being done,
etc.)

If the hash is not included, the client could send an URL to the first
certificate, but the attacker could replace it with the third
certificate.  Given that TLS is a building block that's used in large
variety of applications (and will be used in the future for things we
don't know about yet), it's not totally unplausible that more than one
of these certificates could be acceptable to a server, and it would
behave differently for them.

(You could of course argue that the user should have used different
private/public key pairs when requesting these different certificates,
but that's not always done. You could also argue that since all the
certificates belong to the same user, there's no attack, but I don't
agree with that one.)

Best regards,
Pasi

---

From: [email-masked]
Date: Wed, 30 Apr 2008 19:58:32 +0200 (CEST)

[email-masked] wrote:
>    the WGLC comments, but has some editorial nits. Once Eric    submits
version -06, this will be sent to AD evaluation.

Dear Pasi and Eric,

I would like to inform you and the WG that I submitted a document
(draft-badra-tls-psk-new-mac-aes-gcm), which specifies combinations of
AES_GCM and PSK, and dsecribes a set of ciphersuites with stronger digest
algorithms.

http://www.ietf.org/internet-drafts/draft-badra-tls-psk-new-mac-aes-gcm-02.txt

Since the document is based and heavily borrows from
draft-ietf-tls-ecc-new-mac and draft-ietf-tls-rsa-aes-gcm, I would like to
request that the TLS WG adopts this document as a WG item.

Best regards,
Badra