Subject: [TLS] draft-weimer-tls-previous-certificate-01

From: Florian Weimer <[email-masked]>
Date: Tue, 13 Nov 2012 11:02:44 +0100

I submitted an update to draft-weimer-tls-previous-certificate:

<http://tools.ietf.org/html/draft-weimer-tls-previous-certificate-01>

Compared to the previous version, I added an explanation of the expected 
server-side processing and the interaction with client certificates.  I 
clarified that a handshake which succeeds solely because of a user 
override may still be considered as successful handshake.

I'm not sure how to move this forward.  I think for interoperability 
trials, it makes sense to fix the codepoints for the extensions, but the 
registry requires IETF Consensus, so the RFC has to come first.

-- 
Florian Weimer / Red Hat Product Security Team

---

From: [email-masked] (Martin Rex)
Date: Tue, 20 Nov 2012 01:26:05 +0100 (CET)

> registry requires IETF Consensus, so the RFC has to come first.

On a quick read, the statement in the last paragraph of
Section 2. slightly irritates me:

   A TLS server MAY ignore this extension.  It MUST NOT assume a
   particular order of the presented certificates.  It SHOULD NOT
   include it in the server hello.  A client MUST ignore the extension
   if it is included in the server hello.

This wording has the potential to make the existing mess even for
the certificates in the server's Certificate handshake message worse
than it already is.

If anything, this ought to be EXACTLY the certificate_list sent by the
server as certificate_list in the server's Certificate TLS handshake
message on a previous handshake -- with no additions, no removals
and no reorderings of certificates.  In particular, it should not be
the resulting certificate path that a weird&fancy TLS client creates
by performing a full blown path discovery on the server certificate,
while the originally accompanying path certificate were only used as
hints / candidates for the discovery among other sources (cert caching,
and/or (oh my god) AIA-chasing).

   http://tools.ietf.org/html/rfc2246#page-39

   certificate_list
       This is a sequence (chain) of X.509v3 certificates. The sender's
       certificate must come first in the list. Each following
       certificate must directly certify the one preceding it. Because
       certificate validation requires that root keys be distributed
       independently, the self-signed certificate which specifies the
       root certificate authority may optionally be omitted from the
       chain, under the assumption that the remote end must already
       possess it in order to validate it in any case.

I know there exist several defective TLS server implementations,
that will send arbitrarily garbled certificate_lists in the Certificate
handshake message, although it is pretty clear that the spec has always
required to send a correctly ordered list.

  http://tools.ietf.org/html/rfc6101#section-5.6.2

For implementations with a concept of PKI credential management,
a correctly ordered certificate_list may be an automatic by-product
of the credential management operation that creates (and validates)
the PKI credential.  TLS implementations that lack a concept of
PKI credentials should probably sort the (chain) certificates when
loading the PKI credentials cert chain from external storage,
so that the server admin will immediately get an helpful error message
if any path certificates are missing and any Certificate handshake
messages in the following (thousands) of handshake will be conforming
to the TLS specification without wasting CPU cycles for the very
same operation again and again and again.

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Tue, 20 Nov 2012 13:10:07 +0000

Hi Florian

This seems like a lighter-weight alternative to certificate transparency. While we don't get the client-side benefit (the client can't check if some certificate is legitimate), the server will eventually be notified of any certificate out there pretending to be for it.

One thing I don't like about this proposal, is the bandwidth requirements. You're sending a massive chain in the first handshake message, which will likely slow down the whole thing, because the TCP window is still small at this stage.  Wouldn't it make more sense to have the extension send only a hash of the previous chain?  In that case, the server would not send anything back if it has already seen this hash. If it hasn't, it will send this extension, and then the client can send the whole chain to the server.

There's two ways here. First, you can add a new handshake message that contains the previous certificate. But what I would like even better, is if the server response contained a URL, where the client can POST the certificate chain, in a separate connection that does not interfere with the handshake any more than is needed.

Interoperability trials can be done with a big extension identifier. It's not polite to put this in the big browsers, at least by default, but it's fine for testing. And of course, it's easier to get an RFC when you have some real-world experience.

Yoav

On Nov 13, 2012, at 12:02 PM, Florian Weimer wrote:

> Compared to the previous version, I added an explanation of the expected server-side processing and the interaction with client certificates.  I clarified that a handshake which succeeds solely because of a user override may still be considered as successful handshake.
> 
> I'm not sure how to move this forward.  I think for interoperability trials, it makes sense to fix the codepoints for the extensions, but the registry requires IETF Consensus, so the RFC has to come first.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 28 Nov 2012 15:37:39 +0100

> This seems like a lighter-weight alternative to certificate transparency. While we don't get the client-side benefit (the client can't check if some certificate is legitimate), the server will even…

Right.

> One thing I don't like about this proposal, is the bandwidth requirements. You're sending a massive chain in the first handshake message, which will likely slow down the whole thing, because the TCP window is still small at this stage.

I don't think this will introduce additional network round-trips with 
reasonably sized chains and the current initial CWND recommendations. 
However, the bytes themselves take some time to transmit, adding around 
50ms at 384kpbs with a medium-sized chain.  And this overhead is also 
present during session resumption.

I guess this overhead pretty much kills the idea. 8-(

 >Wouldn't it make more sense to have the extension send only a hash of 
the previous chain?  In that case, the server would not send anything 
back if it has already seen this hash. If it hasn't, it will send this 
extension, and then the client can send the whole chain to the server.
> There's two ways here. First, you can add a new handshake message that contains the previous certificate. But what I would like even better, is if the server response contained a URL, where the cli…

Interesting idea.

It's certainly more difficult to deploy for server operators.  But the 
POST-based indirection would eliminate the mismatch between the maximum 
extension size in the client hello and the maximum chain size, 
simplifying the client implementation.

On the other hand, the certificate submission will not be protected by 
the TLS handshake anymore, so a handshake can be successful with the 
original/genuine certificate, but the previous certificate chain with 
the spoofed one is never submitted.  This would make it simpler for 
attackers to cover their tracks.