Subject: RE: [Speechsc] Default support for TLS?

From: "Jeff Haynie" <[email-masked]>
Date: Thu, 16 Mar 2006 14:34:00 -0500

I'd like to echo Jerry's concern where in plenty of deployments TLS
might be overkill or might be superceded by something which handles
security in a different manner like IPsec.  I could certainly see plenty
of use cases and deployments where a compliant MRCPv2 client doesn't
need TLS and shouldn't have to support it.

________________________________

From: Carter, Jerry [mailto:[email-masked]] 
Sent: Thursday, March 16, 2006 2:13 PM
To: IETF SPEECHSC
Subject: [Speechsc] Default support for TLS?

I've been trying to understand the origin of the language in section
12.2:

    To ensure control channel protection, MRCPv2 clients
    and servers MUST support TLS and SHOULD utilize it
    by default.  Alternative control channel protection
    MAY be used if desired (e.g. IPSEC).

I understand the need for TLS support as a technique for addressing
security concerns in many environments.  TLS is a good thing.  But, I do
not understand why TLS defaults to 'ON'.  

Looking back at the minutes from summer 2004 (e.g.
http://www1.ietf.org/mail-archive/web/speechsc/current/msg00888.html)
when TLS was added, I cannot find anyone arguing for this default value.
Looking at the emails between drafts 6 (where TLS was not the default)
and 7 (when TLS became the default), I can't find anyone arguing for
this change.  When did the SpeechSC group agree to this?

I am concerned here because the majority of telephony deployments, the
MRCP server and client are running on the same trusted network.  In many
cases, the cpu & latency costs for performing an unnecessary encryption
step are desired.  For these buyers, using TLS by default is a barrier
for deployment.

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Thu, 16 Mar 2006 16:06:55 -0800

What this means is that both MRCPv2 clients and servers MUST support TLS
for securing the control channel.
It also means that the MRCPv2 client should always default to using TLS.

This does not mean that the client cannot use a plain TCP pipe to talk
to the MRCPv2 server 
 
"All servers MUST support TLS, SHOULD support TCP without TLS, and MAY
support SCTP."
 
So I agree we should design to be out of the box secure. Security can be
turned off on the client as needed.
 
Sarvi 

	From: Jeff Haynie [mailto:[email-masked]] 
	Sent: Thursday, March 16, 2006 11:34 AM
	To: IETF SPEECHSC
	Subject: RE: [Speechsc] Default support for TLS?

	I'd like to echo Jerry's concern where in plenty of deployments
TLS might be overkill or might be superceded by something which handles
security in a different manner like IPsec.  I could certainly see plenty
of use cases and deployments where a compliant MRCPv2 client doesn't
need TLS and shouldn't have to support it.

	I've been trying to understand the origin of the language in
section 12.2:

	I understand the need for TLS support as a technique for
addressing security concerns in many environments.  TLS is a good thing.
But, I do not understand why TLS defaults to 'ON'.  

	I am concerned here because the majority of telephony
deployments, the MRCP server and client are running on the same trusted
network.  In many cases, the cpu & latency costs for performing an
unnecessary encryption step are desired.  For these buyers, using TLS by
default is a barrier for deployment.

---

From: "Jeff Haynie" <[email-masked]>
Date: Fri, 17 Mar 2006 00:23:04 -0500

OK, I agree security is import in general terms....  I'm interested why
other drafts/RFCs don't take this "security on by default" approach:

1.	SIP (with the exception of Digest, but not transport level)
2.	RTP
3.	HTTP
4.	BCP
5.	SIMPLE
6.	MSRP
7.	SIPPING-CONFIG-FRAMEWORK

I also surveyed the last 4-5 I-D Action drafts and none seemed had this
level of MUST in their Security Considerations.
SIPPING-CONFIG-FRAMEWORK [1] has a more reasonably detailed Security
Consideration section which details conditions when security is
appropriate. However, it still only requires HTTP or HTTPS and is SHOULD
for SIP Authentication for profile delivery servers.

Also, if you don't use secure RTP and SIPS for the endpoints, having TLS
for MRCPv2 most likely is just half-baked since I can just listen
in/redirect the endpoint stream in the middle and get the entire
conversation.  

So, I'm not opposed to security at all - I'm really more interested in
(a) why is it on by default when you're only partially addressing the
issue and thus creating a security vulnerability and (b) questioning a
more thorough look at what Security Considerations might be needed if we
make it a MUST?

Additionally, we're only securing the control channel. If we're going to
get into security details, what about security implications of the data
contained within the SIP/SDP message body itself - is that also required
to be encrypted?  Could a replay or man in the middle attack be created
with session data in the payload as well even if the transport pipe is
secured?   

Jeff

[1]
http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-
08.txt

From: Shanmugham, Saravanan [mailto:[email-masked]] 
Sent: Thursday, March 16, 2006 7:07 PM
To: Jeff Haynie; IETF SPEECHSC
Subject: RE: [Speechsc] Default support for TLS?

Sarvi

---

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Thu, 16 Mar 2006 21:39:27 -0800

Security getting a priority seems IETF wide. I cannot speak for the
other protocols, but if I understand right, we seemed to have got
special attention as we are dealing with Speaker Identification and
Verification, which is biometrics.
 
In section we do secure all 3 levels of protocols, SIP, MRCP control
channel and media. Though the control channel and media is the important
ones here.
 
Requiring that all clients and servers support TLS and SRTP as a MUST is
a requirement for compliance. I don't believe the spec forces you to use
it though. Which is why it allows regular SIP, RTP and TCP as well for
control and media. 
 
So is there an issue I am missing here.
 
Sarvi

	From: Jeff Haynie [mailto:[email-masked]] 
	Sent: Thursday, March 16, 2006 9:23 PM
	To: Shanmugham, Saravanan; IETF SPEECHSC; Dan Burnett
	Subject: RE: [Speechsc] Default support for TLS?

	OK, I agree security is import in general terms....  I'm
interested why other drafts/RFCs don't take this "security on by
default" approach:

	1.	SIP (with the exception of Digest, but not transport
level) 
	2.	RTP 
	3.	HTTP 
	4.	BCP 
	5.	SIMPLE 
	6.	MSRP 
	7.	SIPPING-CONFIG-FRAMEWORK 

	I also surveyed the last 4-5 I-D Action drafts and none seemed
had this level of MUST in their Security Considerations.
SIPPING-CONFIG-FRAMEWORK [1] has a more reasonably detailed Security
Consideration section which details conditions when security is
appropriate. However, it still only requires HTTP or HTTPS and is SHOULD
for SIP Authentication for profile delivery servers.

	Also, if you don't use secure RTP and SIPS for the endpoints,
having TLS for MRCPv2 most likely is just half-baked since I can just
listen in/redirect the endpoint stream in the middle and get the entire
conversation.  

	So, I'm not opposed to security at all - I'm really more
interested in (a) why is it on by default when you're only partially
addressing the issue and thus creating a security vulnerability and (b)
questioning a more thorough look at what Security Considerations might
be needed if we make it a MUST?

	Additionally, we're only securing the control channel. If we're
going to get into security details, what about security implications of
the data contained within the SIP/SDP message body itself - is that also
required to be encrypted?  Could a replay or man in the middle attack be
created with session data in the payload as well even if the transport
pipe is secured?   

	Jeff

	[1]

	What this means is that both MRCPv2 clients and servers MUST
support TLS for securing the control channel.

	It also means that the MRCPv2 client should always default to
using TLS. 

	This does not mean that the client cannot use a plain TCP pipe
to talk to the MRCPv2 server 

	"All servers MUST support TLS, SHOULD support TCP without TLS,
and MAY support SCTP."

	So I agree we should design to be out of the box secure.
Security can be turned off on the client as needed.

	Sarvi 

		I'd like to echo Jerry's concern where in plenty of
deployments TLS might be overkill or might be superceded by something
which handles security in a different manner like IPsec.  I could
certainly see plenty of use cases and deployments where a compliant
MRCPv2 client doesn't need TLS and shouldn't have to support it.

		I've been trying to understand the origin of the
language in section 12.2:

---

From: "Jeff Haynie" <[email-masked]>
Date: Fri, 17 Mar 2006 00:53:13 -0500

I just re-read the security considerations section for draft 9 again and
I guess I misread it earlier.  Jerry stated TLS defaults to 'ON' why is
not true based on the language in 12.2 - since "SHOULD utilize it by
default".  Now that I re-read it *again* you can ignore my concerns ...
since I think the spec satisfies what I was worried about. And with the
complete silence of the list, I guess that is echoed by others (or as
Dave stated previously: only a few people understand security - or maybe
don't care).

Jeff

P.S. I guess the IETF meaning of "compliance" is a little loose anyway
so that doesn't really pose a real world problem. I think the top 2-3
MRCPv2 server implementations I'm aware of aren't (yet) "compliant"
based on the language in the latest draft (which is not the WG problem I
suppose).

From: Shanmugham, Saravanan [mailto:[email-masked]] 
Sent: Friday, March 17, 2006 12:39 AM
To: Jeff Haynie; IETF SPEECHSC; Dan Burnett
Subject: RE: [Speechsc] Default support for TLS?

Sarvi

	Jeff

	[1]

	Sarvi