Subject: [Syslog] New -transport-tls ID - Need Reviews NOW

From: Chris Lonvick <[email-masked]>
Date: Tue, 3 Apr 2007 07:00:31 -0700 (PDT)

Hi Folks,

New ID: 
http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-07.txt

Miao has submitted a revised -transport-tls document.  This came about 
after Sam performed a review and found some items that needed to be 
addressed.

>From Sam:
===vvv===
First, I think the idea of generic certificates will not meet with
consensus of the security community.  It may be OK to use the same
Subject name for all cable modems from a given vendor, but reuse of
private keys is not something we should recommend in an IETF standard.

In general, preferring dnsname subjectAlternativeName to CN in the
subject field seems preferable.  Why does this specification use cn
rather than either always using dnsname or using a procedure similar
to that in RFC 2818.

The text seems confused about what authentication is required when.
Section 5.1 implies that authentication of receivers is optional but
the text requires it.

Are senders and relays required to have a certificate and to use that
certificate?
===^^^===

There is a lengthy discussion which can be found in the archives.

David and I feel that there are enough significant changes to this 
document that we'd like a WG review before we pass it back to Sam.

Please read this document and send a note back the the mail list - even to 
say that you have no problems with the document.  I'll ask that everyone 
overlook typo's and small grammar problems at this time.  We need to make 
sure that the document:
- addresses Sam's concerns,
- meets the stated goals of our charter,
- is technically sound, implementable, and deployable,
- is a good thing to do for syslog.

Many thanks,
Chris

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: Eliot Lear <[email-masked]>
Date: Tue, 03 Apr 2007 16:48:55 +0200

Hi Chris,

I've taken a look at this document, and I have just two comments.  In 
section 4.2.2:
>    A client's certificate must be associated with a unique private key .
>    Private keys MUST NOT be shared between clients.

This is not part of the protocol, often beyond the control of the syslog 
implementor, and hence should be stricken.  If you want to have a 
discussion about the shared use of private keys, please move it into 
Security Considerations with non-normative text.

Similarly, Section 4.2.3 overreaches:

>    Syslog applications MUST be implemented in a manner that permits
>    administrators, as a matter of local policy, to select the
>    cryptographic level and authentication options they desire.
>   

While I understand the desire for algorithm agility, this may not be 
possible in embedded applications.  I would state this as a SHOULD.

Eliot