[TLS] Downgrade prevention with authenticated list of ciphersuites?

[Seth David Schoen <[e-mail]>]

I'm wondering if there's any existing proposal for a mechanism to prevent
ciphersuite downgrade attacks by authenticating the list of ciphersuites
offered by a TLS server.  One way to do this might be to put the list
somewhere in the server's certificate (maybe someone's already specified
a way to do so?), like a "subject offered ciphersuites list".

The advantage of this is that a network attacker -- I think -- can't
downgrade the connection to a less secure ciphersuite* than the
most secure one supported by both ends (unless they can also cause
misissuance of a certificate).  The disadvantage is an extreme decrease
in the flexibility of server configuration for a system administrator,
because they need to get certs reissued in order to make changes to the
ciphersuite list, at least if they want certain kinds of changes to have
any effect.  And it provides another way for connections to fail due to
a misconfiguration.

It seems like this policy would have good backward compatibility
properties if the extension conveying this information is not marked
critical.  If a client doesn't understand the list, it ignores it and is
just as vulnerable as today.  If it does understand the list, it always
uses what it regards as the most secure ciphersuite that's supported by
both ends.


* However, as Daniel Gillmor pointed out to me, they can still cause
  other kinds of non-ciphersuite-related downgrades (like a TLS
  protocol version downgrade) that could have security consequences
  that are as bad or worse.

-- 
Seth Schoen  <[e-mail]>
Senior Staff Technologist                       https://www.eff.org/
Electronic Frontier Foundation                  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109       [phone] x107