> > Probably lower case. The point is confidentility is meaningless 
> > without authenticaion.
> 
> Well... maybe it is just a wording issue. Are we actually 
> REQUIREING a sender to authenticate the receiver in all 
> cases? If so, we should state that. My impression so far is 
> that this is something that is optional and at the discretion 
> of the sender or the operator configuring it. If so, we 
> should state that clearly too. As an implementor, I am unsure 
> what to do if I use the above text as a guideline.
> 

It does not define what authentication to use. I will check the text to make
sure it expressed this point. 


> > 
> > TLS transport does not check HOSTNAME in syslog message because 
> > transport must not depend on content of the payload (or 
> else a relay 
> > must check the content of each message).
> 
> wouldn't it still be useful to put that information into the 
> security considerations? Would it be useful to add something 
> to the security considerations of -protocol (on the lines of 
> "if the transport provides identification of the sender, a 
> receiver MAY / SHOULD verify the provided HOSTNAME)"?
> 
> WG comment appreciated.

I am not sure, but my perception is -transport and -protocol should be as
independent to each other as possbile. 

> > Tom and I discussed this issue on the mailing list. TLS 
> protocol has 
> > its mandatory suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA), and TLS 
> > specification says that if application profile(syslog-tls in this 
> > case) does not specify a mandatory cipher suite, TLS 
> mandatory suite 
> > will apply. So, no need to specify one in this specification.
> 
> Ahh... that was the message I did not find in the archive. 
> Thanks for bringing it up again. That obiously solves the 
> interop problem. However, I am still of the view that we 
> should advise operators to use strong suites in the security 
> considerations section.
> 

Yes, I think TLS also advises the operator strong suites. 



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

Reply via email to