Re: New Version: draft-ietf-syslog-dtls-02

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