Subject: Re: [Syslog] js review of draft-ietf-syslog-dtls-01.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 6 Mar 2010 01:25:44 +0100

On Mon, Feb 22, 2010 at 05:54:48PM +0100, Juergen Schoenwaelder wrote:
 
>    Both transport receiver and transport sender implementations MUST
>    provide means to generate a key pair and self-signed certificate in
>    the case that a key pair and certificate are not available through
>    another mechanism.
> 
> I do not know the idea behind this requirement is or how I comply to
> it. Is this expressing a requirement for the management interface of
> the box? Or is the idea that this is used in some automated fashion
> (which likely does not make sense but would be harmful if read this
> way).

This text seems to be unchanged in -02 and I still do not know how I
implement this MUST. On Unix systems, people use tools such as openssl
to create certificates etc. while a syslog implementation would
typically links against a DTLS library and would not have itself a
builtin option to create a self-signed certificate. So is this text
putting up an implementation requirement that a syslog daemon must
have a _built-in_ option to create a self-signed certificate? My
concern is that key / certificate management is something pretty
unrelated to the syslog over DTLS transport implementation itself and
hence it is somewhat unclear how to implement the MUST.

>    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.
> 
> What is an end-entity certificate? And how do I correlate sent or
> received data?

The second part has been clarified in -02 but I still wonder what an
"end entity certificate" is. Probably this is meant:

   The transport receiver and transport sender SHOULD provide
   mechanisms to record the certificate or certificate fingerprint of
   the remote endpoint for the purpose of correlating an identity with
   the sent or received data.
 
>    [...] Once the transport receiver gets a close_notify from the
>    transport sender, it MUST reply with a close_notify.
> 
> Is it our job to define this? Does DTLS not specify how to handle
> such DTLS alerts?

I am still wondering why we need to specify this...

/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: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 5 Mar 2010 17:01:30 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Juergen Schoenwaelder
> Sent: Friday, March 05, 2010 4:26 PM
> To: [email-masked]
> Subject: Re: [Syslog] js review of draft-ietf-syslog-dtls-01.txt
> 
[Joe] There was some discussion of this on the list. The conclusion was
that this was not a GUI requirement but could be met by a script to
generate a certificate an configure its use, which didn't see onerous to
implementers.  The same text is in the syslog TLS RFC.  

> >    The transport receiver and transport sender SHOULD provide
mechanisms
>    the sent or received data.
[Joe] End entity is RFC 5280 terminology.  It refers to the owner of the
public key that is used in the authentication versus a certificate
authority that signs certificates. 

> I am still wondering why we need to specify this...
[Joe] This is the same text as we used in the syslog TLS document. That
being said it is likely redundant. 

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

---

From: "tom.petch" <[email-masked]>
Date: Mon, 8 Mar 2010 15:34:41 +0100

----- Original Message -----
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>;
<[email-masked]>
Sent: Saturday, March 06, 2010 2:01 AM

> implementers.  The same text is in the syslog TLS RFC.

The key point is
"The same text is in the syslog TLS RFC.  "
We established consensus on this and got it accepted by all parties (IETF, IESG
etc) so there needs to be a very good reason to change it, and I have not yet
heard one.

> being said it is likely redundant.

The key point is 
"This is the same text as we used in the syslog TLS document.  "
We established consensus on this and got it accepted by all parties (IETF, IESG
etc) so there needs to be a very good reason to change it, and I have not yet
heard one.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Mar 2010 17:35:09 +0100

On Mon, Mar 08, 2010 at 03:34:41PM +0100, tom.petch wrote:
> We established consensus on this and got it accepted by all parties
> (IETF, IESG etc) so there needs to be a very good reason to change
> it, and I have not yet heard one.

I am not convinced by the argument but I will shut up.

> etc) so there needs to be a very good reason to change it, and I have not yet

Same as above. It is just good to receive an answer to points raised.

/js