Subject: [Syslog] Please review draft-ietf-syslog-dtls-01

From: "Anton Okmyanskiy (aokmians)" <[email-masked]>
Date: Fri, 19 Feb 2010 16:15:07 -0600

Hi!

Chris asked me to review this draft.  Comments below. 

Section 1

"DTLS has been mapped onto different transports (i.e.  UDP [RFC0768] and
DCCP [RFC4340] ), to secure syslog in more situations."

AO: Remove " to secure syslog in more situation".  This paragraph is
giving a general overview of DTLS and it is independent of syslog.
Otherwise, reader is confused into thinking that DTLS was mapped as
described for the benefit of syslog. 

"For systems where DCCP is either not available or not usable (such as
the aforementioned situation),"

AO: Don't see any "aforementioned situation" in text or don't get the
reference.

"In those circumstances where reliability or ordering is important,
SYSLOG over TLS is appropriate."

AO: This would be best moved to end of first paragraph where Syslog over
TLS is introduced. 

"Syslog over TLS does not provide application layer acknowledgements and
therefore is not a fully reliable solution."

AP: Same comment as above.  This criticism leaves a question as to
whether the newly defined mapping solves this problem. If not, it should
be pointed out as a drawback of both mappings, not just TLS. Possibly,
best addressed elsewhere in a Reliability section.

Section 2

"A "DTLS client" is an application that can initiate a DTLS Client Hello
to a server."

AO: Further in the document we have...

" The transport sender initiates a DTLS connection by sending a DTLS
Client Hello to the transport receiver.

"A SYSLOG transport sender is always a DTLS client and a transport
   receiver is always a DTLS server."

AO: Why do we need 4 terms then?  If they are equivalent, may be best
to just add further description to transport sender/receiver and stick
them?   

Section 3

" The security requirements for Syslog are discussed in [RFC5425]."

AO: Suggest changing to: " The security requirements for Syslog are
discussed in Section 2 of [RFC5425] and apply to this transport
mapping."

Section 5.3.1

"   The transport receiver and transport sender SHOULD provide
mechanisms
   to record the end-entity certificate for the purpose of correlating
   it with the sent or received data."

AO: Which exact fields of the certificate?  Surely not entire
certificate. Maybe full DN + SubjectAltName + AuthorityKeyIdentifier?

Section 5.4.1

The message size SHOULD NOT exceed the DTLS maximum record size
limitation of 2^14 bytes.

AO: SHOULD NOT or MUST NOT?

When mapping onto different transports, DTLS has different record size
limitations.

AO:  Can we mention limitations with UDP and DCCP here, so people don't
have to dig and do the math on extra size header overhead?  

Anton.

---

From: Richard Graveman <[email-masked]>
Date: Sat, 20 Feb 2010 00:08:33 -0500

> Chris asked me to review this draft.  Comments below.

Likewise. Glad to look at it.

Sorry for the lateness of these comments. I think the draft is in
good shape, and, in view of the comments already posted, ready to
go to the AD after one more pass.

I have not followed this work, because the applications with which
I am involved already implement RFCs 4301-4303-4306. These seem
to me to provide all of the same security coverage, and there is
reluctance to add another security suite. (Taking this another step,
the same goes for syslog over TCP in my case.)

Just a few comments:

1. RFC 5746 updates DTLS, so it is worth a normative reference.

2. Last week, at Fast Software Encryption, Xiaoyun Wang estimated that
SHA-1 collisions would be found within one to two years, so perhaps
one of the AES-based MACs or combined modes is a safer mandatory-to-
implemement cipher suite. AES-without-SHA is also a smaller crypto-
footprint for constrained devices. (Of course, collisions do not necessarily
compromise HMACs, but ...)

3. The Introduction states that a high rate of lost packets is a
reason for using UDP. It is also a reason for using TCP.

4. Do relays guarantee ordering? I thought timestamps (or syslog-sign)
was all one had to go on.

5. In Section 5.1, paragraph 2, sentence 2, a word or two may be
missing: " ... may not be able to assure ..."?

6. Then, also in 5.1: "When TCP is used syslog over DTLS MUST NOT be
used." Well, I have not seen much discussion of this, but does
anything say that I cannot use TCP for some syslog messages and UDP
for others?

7. Why have pre-shared keys as an alternative to certificates been
rejected?

Richard Graveman
RFG Security, LLC
[email-masked]

---

From: "tom.petch" <[email-masked]>
Date: Tue, 23 Feb 2010 14:53:02 +0100

Hi Anton,

inline

Tom Petch

----- Original Message -----
From: "Anton Okmyanskiy (aokmians)" <[email-masked]>
To: <[email-masked]>
Sent: Friday, February 19, 2010 11:15 PM
Subject: [Syslog] Please review draft-ietf-syslog-dtls-01

> described for the benefit of syslog.

What I find that phrase adds is a justification for syslog over DTLS to exist;
it caters for situations where the TCP problems alluded to in the previous
paragraph are an issue; perhaps rephrase it as
"which makes it possible to secure applications such as syslog in a greater
variety of situations".

> AO: Don't see any "aforementioned situation" in text or don't get the

Again, I think that this harks back to para 2 which puts the case for UDP and
implicitly against DCCP.

> AO: This would be best moved to end of first paragraph where Syslog over

Yup

> best addressed elsewhere in a Reliability section.

No, it does not change the application layer protocol, and this is a general
weakness of TCP which seems not to be as well known as it might be and
so should be included; perhaps the first paragraph is best.

We have a delicate juggling act here, that syslog over TLS is the IESG-mandated
solution, because it provides flow control, and so we cannot be too critical of
it,
yet need to criticise it in order to justify the existence of sylog over DTLS.

> to just add further description to transport sender/receiver and stick

Bear in mind that RFC5424 prescribes a set of syslog terms that have nothing to
do with (D)TLS and those should be used as is; we then need terms for the
(D)TLSish things and I think that this is the minimum necessary.  Who is client
and who server is a big deal with (D)TLS and needs to be explicitly stated in
application terms.

> discussed in Section 2 of [RFC5425] and apply to this transport

Yup

> certificate. Maybe full DN + SubjectAltName + AuthorityKeyIdentifier?

I think that these are murky waters; something similar cropped up on the TLS
list recently with the view that this is really a task for PKIX, even if they
show no signs of wanting to take it on.  Outside PKIX, I think that we should
restrict ourselves to entire certificates (or to fingerprints thereof, when
appropriate).

> have to dig and do the math on extra size header overhead?

Another murky water on which I will pass.

tp

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 23 Feb 2010 16:46:09 +0100

On Tue, Feb 23, 2010 at 02:53:02PM +0100, tom.petch wrote:
 
> We have a delicate juggling act here, that syslog over TLS is the
> IESG-mandated solution, because it provides flow control, and so we
> cannot be too critical of it, yet need to criticise it in order to
> justify the existence of sylog over DTLS.

You do not have to 'criticize' SYSLOG over TLS/TCP - there will be
situations where there simply is no TCP, see 6lowpan et al. The best
thing is to concentrate on defining how SYSLOG over DTLS works and to
leave out any discussion about 'shortcomings' of TLS/TCP or how to
choose the best SYSLOG transport for a given network for future
documents.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "tom.petch" <[email-masked]>
Date: Wed, 24 Feb 2010 20:19:31 +0100

---- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Anton Okmyanskiy (aokmians)" <[email-masked]>; <[email-masked]>
Sent: Tuesday, February 23, 2010 4:46 PM
Subject: Re: [Syslog] Please review draft-ietf-syslog-dtls-01

> choose the best SYSLOG transport for a given network for future

I see many I-Ds criticised for failing to say why they should exist.  The
limitations of TCP and the attractions of UDP justify this I-D so I regard those
preliminary paragraphs as a necessary part of this I-D.  Ir might be called an
applicability statement.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Feb 2010 23:45:34 +0100

On Wed, Feb 24, 2010 at 08:19:31PM +0100, tom.petch wrote:

> I see many I-Ds criticised for failing to say why they should exist.
> The limitations of TCP and the attractions of UDP justify this I-D
> so I regard those preliminary paragraphs as a necessary part of this
> I-D.  Ir might be called an applicability statement.

Good luck with spelling out the "limitations of TCP" in a way that
does not look hand waving and passes the reviews without triggering
nasty questions. Leave the discussion which transport to choose in
which situation to a future SYSLOG applicability statement document.

/js

---

From: "David Harrington" <[email-masked]>
Date: Thu, 25 Feb 2010 09:49:25 -0500

Hi,

(chair hat ON)

  The WG under this charter will standardize a DTLS transport for
syslog,
  providing a secure transport for syslog messages in cases where a
  connection-less transport is desired. The threats that this WG will
  primarily address are modification, disclosure, and masquerade. A
  secondary threat is message stream modification.  These are
consistent
  with those addressed in RFC 5425.

Our job is to define a DTLS transport for syslog. 
I don't interpret the charter as saying we need to show why TCP is
inadequate.
syslog/tls is mandatory-to-implement. syslog/dtls is not.

Syslog/dtls is being designed for cases where a connection-less
transport is desired. We provide the specification of how to do so in
a standardized manner.  

(chair hat OFF)
Applicability is an operational/deployment decision.
It might be good to state that in the document.
I would be fine with a statement that says syslog/dtls SHOULD be used
when the operational environment demands a secure connection-less
transport, but syslog/tls SHOULD be used in normal operating
environments for purposes of interoperability.

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Wednesday, February 24, 2010 5:46 PM
> To: tom.petch
> Cc: [email-masked]
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/syslog
>