[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] draft-weimer-tls-previous-certificate-01
From:       Florian Weimer <fweimer () redhat ! com>
Date:       2012-11-28 14:37:39
Message-ID: 50B621B3.4000008 () redhat ! com
[Download RAW message or body]

On 11/20/2012 02:10 PM, Yoav Nir wrote:

> 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.

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 client can POST the certificate chain, in a separate \
> connection that does not interfere with the handshake any more than is needed.

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.

-- 
Florian Weimer / Red Hat Product Security Team


[prev in list] [next in list] [prev in thread] [next in thread]