Subject: [Syslog] transport-tls vs. syslog-sign

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 16 May 2008 15:45:35 +0200

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?

Thanks,
Rainer
_______________________________________________
Syslog mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/syslog

---

From: [email-masked]
Date: Fri, 16 May 2008 10:28:20 -0400

> [Rainer] Hi all,

[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.

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 16 May 2008 17:06:45 +0200

Hi Robert,

thanks again for the excellent description. My comments below...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, May 16, 2008 4:28 PM
> To: Rainer Gerhards
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Syslog] transport-tls vs. syslog-sign
> 
> > [Rainer] Hi all,
> >

[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

---

From: [email-masked]
Date: Fri, 16 May 2008 11:16:02 -0400

"Rainer Gerhards" <[email-masked]> wrote on 05/16/2008 11:06:45 

> distribution. In fact, -sign focuses very much on the distribution. 

...
> some ideas. Even the relationship between those two is not spelled

I make this distinction on authentication.  -tls authenticates the sender 
of the message.  -sign authenticates the contents and creator of the 
message.  Both have their uses, and they are independent concepts.  I find 
in practice that for syslog style operation I am usually satisfied with 
-tls plus the knowledge that the sender has done whatever is appropriate 
to ensure that message contents are appropriate.  But, there are other 
syslog situations where that is not a reasonable assumption, and -sign is 
then needed.

R Horn

---

From: "tom.petch" <[email-masked]>
Date: Tue, 20 May 2008 10:43:43 +0200

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

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Wed, 21 May 2008 10:54:40 -0700

I agree it might be a good idea to spell out the relationship between
the two.  We can add a section to syslog-sign, or presumably add a
section to both that "mirror" each other.  Both have different uses, so
I am not sure how much effort should be spent beyond that - I am
concerned despite the best intentions, it might turn out to not be
really helpful in the end and merely slow things down.   

--- Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Friday, May 16, 2008 8:16 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Syslog] transport-tls vs. syslog-sign

"Rainer Gerhards" <[email-masked]> wrote on 05/16/2008
11:06:45

...
> some ideas. Even the relationship between those two is not spelled

I make this distinction on authentication.  -tls authenticates the
sender 
of the message.  -sign authenticates the contents and creator of the 
message.  Both have their uses, and they are independent concepts.  I
find 
in practice that for syslog style operation I am usually satisfied with 
-tls plus the knowledge that the sender has done whatever is appropriate

to ensure that message contents are appropriate.  But, there are other 
syslog situations where that is not a reasonable assumption, and -sign
is 
then needed.

R Horn