I don't support the idea of using new SCSVs as bitflags for things
unrelated to cipher suite selection that would more properly be
negotiated by an extension. I realize RI uses an SCSV, but it was
clearly an exceptional case.
I also think this is not a problem that many client apps need to solve
right now and it's not the best way to promote the usage of client certs.
However, to be fair to Mohamad's proposal ...
On 03/27/2012 05:24 PM, Eric Rescorla wrote:
> As far as I can tell this still has an active attack. The attacker
> simply replies
> to the client by aborting the handshake as shown in S 2. At this point,
> the client has the option of connecting normally (and disclosing his
> cert) or not connecting. This is the same downgrade issue all other
> proposals have.
But by this same logic, aren't TLS 1.0, 1.1, 1.2, and all current
extensions (with the exception noted previously) also subject to this
downgrade attack? Is this not an argument against them too?
If the downgrade you're talking about is one of browser's behavior
(i.e., if the highest protocol level handshake fails they retry with a
lower version on a different TCP connection) then that seems almost out
of scope for [TLS]. What could be said in a transport layer spec that
could help prevent application layer logic from subverting it in this way?
- Marsh
_______________________________________________
TLS mailing list
TLS@...
https://www.ietf.org/mailman/listinfo/tls
