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

[Chris Lonvick]

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
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog

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

[Eliot Lear]

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


___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog