Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis

[Ilari Liusvaara <[e-mail]>]

On Mon, Dec 01, 2014 at 12:56:38AM -0800, Ryan Sleevi wrote:
> 
> Plus, there are plenty of libraries where the ciphersuite implementation
> is semi-independent of the certificate validation.
> 
> Perhaps the largest deployment is Chrome, which uses a separate TLS
> library (NSS, BoringSSL) than its PKI validation (OS APIs such as
> CryptoAPI, Security.framework, or Android Keychain Services). You can
> certainly have skew where the TLS client supports a modern suite of
> algorithms, but the underlying platform does not. On Windows XP, this is
> the SHA-2 family (pre-SP3) and ECDSA (pre-Vista), and on OS X, some
> releases had some buggy ECDSA handling.
> 
> There are also a number of embedded TLS stacks that provide the
> cryptographic framework for TLS, but then defer to external components (or
> hardware) for trust validation.
> 
> I just mention these as real world cases where ciphersuites alone are
> insufficient (although SignatureAndAlgorithms generally is... except where
> it isn't)

Plus, it is easier to implement just ECDH than ECDSA over given curve,
so implementations that can do ECDH over curve X but not ECDSA over
curve X (but can do ECDSA over some other curve) should not be surprising.

This might especially be so for CFRG curves.

Vice versa might also happen (can do ECDSA over X, but not ECDH over
X).


Also, the algorithm lists can't specify restrictions like that ECDSA
P-256 only works with SHA-256 and P-384 only works with SHA-384 (because
code to do P-256 with SHA-384 is buggy).



-Ilari