Hi Rich,
I appreciate the review.
RFC 4279 also says:
=====
The ciphersuites defined in this document are intended for a rather
limited set of applications, usually involving only a very small
number of clients and servers. Even in such environments, other
alternatives may be more appropriate.
If the main goal is to avoid Public-Key Infrastructures (PKIs),
another possibility worth considering is using self-signed
certificates with public key fingerprints. Instead of manually
configuring a shared secret in, for instance, some configuration
file, a fingerprint (hash) of the other party's public key (or
certificate) could be placed there instead.
=====
This is why we have the parts in there about "MUST be able to generate a
self-signed cert" (identical language to RFC 5425), and the use of
fingerprints (reference back to 5425).
I understand what you're saying about SHA-1, however I don't think that
will be an issue since the signature on the certificate is not even
verified if you use fingerprints. I'll also back up and say that I havn't
seen the IESG give specific guidance about not using SHA-1.
Thanks,
Chris
On Fri, 5 Mar 2010, Richard Graveman wrote:
I've looked over these changes and feel that they address the WGLC comments
that were received. ?I'd appreciate it if the people who did the reviews
would also do a check.
Requiring certificates is a lot of extra baggage for worsened
security. All the commonly encountered certificates today are based on
signatures of weak hash functions, primarily SHA-1. Cipher suites
like:
0x00,0xA8 TLS_PSK_WITH_AES_128_GCM_SHA256 [RFC5487]
0x00,0xA9 TLS_PSK_WITH_AES_256_GCM_SHA384 [RFC5487]
do not suffer from the twin disease of weak and inefficient security
and ought to be an option, as Tschonfig and Eronen say in 4279:
... pre-shared keys may be more convenient from a key
management point of view. For instance, in closed environments
where the connections are mostly configured manually in advance,
it may be easier to configure a PSK than to use certificates.
Another case is when the parties already have a mechanism for
setting up a shared secret key, and that mechanism could be used
to "bootstrap" a key for authenticating a TLS connection.
This is precisely the environment is which I would expect to find a
lot of syslog, as opposed to "TLS on the Web."
Rich Graveman
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
