Rainer I am uncomfortable with the statement that TLS cannot authenticate the originator. It is true insofar as TLS is transport level and so cannot authenticate the message origin but I think that you are suggesting more than that.
The fact that when relays are involved, it only authenticates the last hop is worth a mention, but for me is not relevant. I see (or don't see:-) relays as rare and esoteric so security that works well in their absence is still very good security (for me). I appreciate that for others, relays are essential. Also, I can conceive of the initial hops being in a trusted location so that it is only the final hop where security is of concern, so even with relays, TLS may provide security just where it is needed. And, if the topology is the other way round, where it is the latter hops which are in a trusted location - which seems to me less likely - then it is the first hop that needs the security in which case it is the first relay that needs to perform the certificate check. Whatever, I do see the checking of the authenticity of the client as important, in fact as the most important part of this I-D. Tom Petch ----- Original Message ----- From: "Rainer Gerhards" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[email protected]>; <[EMAIL PROTECTED]> Sent: Friday, May 16, 2008 5:06 PM Subject: Re: [Syslog] transport-tls vs. syslog-sign > Hi Robert, > > thanks again for the excellent description. My comments below... > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Friday, May 16, 2008 4:28 PM > > To: Rainer Gerhards > > Cc: [email protected]; [EMAIL PROTECTED] > > Subject: Re: [Syslog] transport-tls vs. syslog-sign > > > > > [Rainer] Hi all, > > > > > > I did a cross-check today between the two drafts. Both require > > > certificates. Syslog-sign actually includes distribution policies in > > > section 5. There is a huge difference between the ways certificates > > are > > > handled in both drafts. > > > > > > Implementing both will at least require duplicate/different code for > > > like tasks. Same goes for the administration. I have not yet a > > solution > > > proposal, but I would like to make the WG aware of this fact. > > > > > > What are your thoughts? > > > > > > > [RJHorn] > > > > To some degree you are describing the present state of implementation > > for > > certificate and key management. It's a mess. > > > > I expect that in the end this will generalize into: > > > > - For each different application purpose (browsing, signing, > > prescribing, > > logging, payments, ...) there will be stores for > > - Private key information (used locally to sign, etc.) > > - Trusted individual certificates (e.g., self-signed but not > > restricted > > to self-signed) > > - Trusted signing certificates > > - Anchors of Trust > > > > With luck there will emerge common maintenance methods, but they sure > > aren't there now. For each browser I've got a different maintenance > > method for trusted signers, trusted individual certificates, and > > private > > key information. I don't have any browsers that actually manage usig > > an > > anchor of trust. And that is for the single application purpose of > > browsing. The browsers are all different. > > > > The nature and meanings of trust is dependent on the application > > purpose, > > so you should not have a single single store. We will always need a > > way > > to have different stores for different purposes. Meanwhile, we > struggle > > with every implementation having different maintenance methods. At > > least > > they agree on the PKCS format for exchanging these elements. I don't > > see > > syslog as the proper venue for doing more than defining use cases for > > this. Longer term, I hope that a common agreement emerges on how to > > name > > and organize these stores so that common maintenance can be > > implemented. > > > > For the specifics of sign vs transport, is there an application > > difference > > between being an authenticated sender of messages, and being an > > authenticated signer of messages? I think that there is, so they do > > need > > to be separate stores. I haven't looked at the details of > > functionality > > required by sign because I haven't had any real uses yet for signing > > the > > messages. The differences should be reducable to using different > > stores > > for key and certificate information, and performing different > > operations > > (e.g., signing) on the messages. > > [Rainer] > The differences I see is that between the two there are differences in > what modes can be used. For example > > -sign -transport-tls > x.509 yes yes > fingerprints no yes > openPgP yes no > (other) yes (N/A) > > Also, -sign specifies how certificates are distributed (section 5.2, 5.3 > among others). -transport-tls does not talk about certificate > distribution. In fact, -sign focuses very much on the distribution. > > -sign also describes something that one could call a threat model in its > security considerations (section 8). There is a strong overlap between > these two. For example, -sign 8.8 is addressed in -tls 3 > (confidentiality) and could be referenced as a solution. On the other > hand, -tls does not spell out countermeasures found in -sign against the > remaining threats. > > So I think it is more than just different stores. I think both drafts > define the threat model, talk about authentication, and talk (or be > silent) on certificate distribution. There are just a number of > differences between them. > > As I outlined in my mail yesterday, -tls cannot really authenticate the > originator. -sign can do that. -sign cannot provide confidentiality. > -tls can do that. So a really secure system would need to utilize both. > Then, it would at least be useful to have the same set of drafts reuse > some ideas. Even the relationship between those two is not spelled > out... > > If this inconsistency is acceptable in order to finally get things done, > that's fine with me. I just wanted to make sure everybody is aware of > that situation. > > Rainer > _______________________________________________ > Syslog mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
