Subject: [Syslog] DTLS renegotiation

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 7 Mar 2010 14:29:25 -0800

Richard pointed out that we should cover issues DTLS renegotiation.
Recently, as you may have been aware, there have been vulnerabilities
discovered with TLS renegotiation.   In general, DTLS tends to be less
vulnerable to the attacks described, but there still can be issues.
During renegotiation new parameters can be renegotiated for the
connection and, with most libraries, the application does not know that
a change occurred.  In general I think it would be best to avoid
renegotiation, however this means that in the case of extremely long
lived connections the connection will need to be broken and started
again at some point.  

Below is the text I suggest adding to the security considerations of the
document.  

8.1 DTLS Renegotiation

TLS and DTLS renegotiation may be vulnerable to attacks described in RFC
5746.  Although RFC 5746 provides a fix for some of the issues,
renegotiation can still cause problems for applications since connection
security parameters can change without the application knowing it.
There for it is RECOMMENDED that renegotiation be disabled for syslog
over DTLS.   If, for some reason, renegotiation is allowed then the
specification in RFC 5746 MUST be followed and the implementation MUST
make sure that the connection security parameters do not change during
renegotiation.

---

From: "tom.petch" <[email-masked]>
Date: Wed, 10 Mar 2010 20:37:53 +0100

---- Original Message -----
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, March 07, 2010 11:29 PM
Subject: [Syslog] DTLS renegotiation

> make sure that the connection security parameters do not change during

I think that the last sentence goes too far and should be more like

" If renegotiation is allowed then the
> make sure that the connection still has adequate security and that any
identities extracted from client and serverthe certificates do not change during
> renegotiation.

Well, a bit clumsy, but I would like to be specific on those two issues.  They
are nothing to do with the problem that RFC5746 addresses but the work leading
up to RFC5746 did show that these are related issues with renegotiation.

Tom Petch

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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 11 Mar 2010 22:07:44 -0800

Hi Tom,

The text I suggested is a bit vague.  I like your replacement text.

Joe

> identities extracted from client and serverthe certificates do not
change
> during
> > renegotiation.
> 
> Well, a bit clumsy, but I would like to be specific on those two
issues.
> They