Re: [TLS] NIST TLS recomendations

[Bodo Moeller <bmoeller@xxxxxxx>]

On Wed, Nov 01, 2006 at 09:19:52AM -0500, Ray Perlner wrote:

[...]
> Upon our review of the TLS protocol (as specified 
> in draft-ietf-tls-rfc4346-bis-01), we noted that 
> the IETF has up to this point made the design 
> decision not to use the key derivation function 
> specified by NIST SP 800-56a. This KDF provides 
> certain guarantees as to the security of schemes 
> that use it. We therefore have evaluated whether 
> those same guarantees are provided within the 
> currently specified TLS v1.2 protocol. This 
> process led us to recommend the following 
> modifications to TLS v1.2 addressing both the 
> security issues that would be resolved by using 
> our KDF, and other security issues that arise in 
> the context of the TLS protocol:

Thank you for contributing the list of proposed modifications.
Just some brief comments at this time:

[...]
> Page 27: Section 7.2.2
> While it is required that certain alerts must be 
> fatal, it is not currently required that said 
> alerts are sent in the first place. For example, 
> if the client certificate is not of the 
> negotiated type, but the server is capable of 
> parsing the certificate, we believe that a 
> compliant implementation of TLS should reject the 
> certificate and send a fatal error 
> (unexpected_message most likely,) however the 
> document does not currently seem to mandate this. 

I don't think that this particular change is warranted.  In many
situations, servers request client authentication via a certificate,
but can tolerate unauthenticated clients as well.  In a scenario where
unauthenticated clients are welcome, authenticated clients may be
given the privilege to access services that are not available to
unauthenticated clients.  (E.g., for the case of an SMTP server, any
client can send e-mail to addresses that are local to the server; only
certain authenticated clients can send e-mail to remote addresses.)
There is no compelling reason to have the TLS handshake fail if a
client that tries to authenticate itself by presenting a certificate
presents a certificate that the server cannot handle: In this case the
client may simply end up as an unauthenticated client, which may very
sell sufficient for whatever services the client actually needs to
use.

If you think that the current wording is not strict enough, then the
change that should be done is not to force these alerts to become
fatal.  Possibly the specification should more clearly point out that,
in the situations where such alerts have to be sent by the server
since the are problems about verifying the client certificate, the
contents of the client certificate cannot be trusted in any way and
must be ignored.


_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls