Subject: [Rserpool] TLS cipersuites for Rserpool

From: [email-masked]
Date: Mon, 15 Sep 2003 14:41:11 -0500

Although we have reached consensus on TLS for securing the Rserpool
infrastructure, we have not discussed TLS cipher suites.  TLS has a very
long and growing list of ciphersuites.  They vary in strength.  Security
experts want strong security.  Application developers worry about
interoperability.  The answer to this is for applications to mandate a
ciphersuite along with one or more shoulds for backward compatibility.

I am including the SIP RFC 3261 security section as an example.
In the SIP specification there is the following text:

The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] MUST be supported at
   a minimum by implementers when TLS is used in a SIP application.  For
   purposes of backwards compatibility, proxy servers, redirect servers,
   and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA.
   Implementers MAY also support any other ciphersuite.

For Rserpool we need to secure the following:

PU <----> ENRP Server
PE <----> ENRP Server
ENRP server <-----> ENRP Server

I recommend Rserpool security text as follows (for ENRP and ASAP security
sections):

The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a minimum
by implementers of TLS for Rserpool.   For purposes of backwards
compatibility, ENRP SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA.
Implementers MAY also support any other ciphersuite.

I'll get Eric Rescorla's advice about this TLS cipher suite being the right one
to make mandatory to support and also his take on backward compatibility.  We might not need
this in ENRP assuming that everyone will write new code for Rserpool
infrastructure.

Any comments?

-- maureen

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

---

From: Peter Lei <[email-masked]>
Date: Mon, 15 Sep 2003 15:59:25 -0500

Maureen,

I agree with mandating the AES-128-CBC/SHA cipher, but what
is the rationale for the SHOULD for the 3DES cipher?  What
"backward compatibility" is desired/required here?

thanks,
--peter

[email-masked] wrote:
> to make mandatory to support and also his take on backward compatibility.  We
 > might not need this in ENRP assuming that everyone will write new code
 > for Rserpool infrastructure.

---

From: Peter Lei <[email-masked]>
Date: Mon, 15 Sep 2003 15:59:25 -0500

Maureen,

thanks,
--peter

---

From: "bill" <[email-masked]>
Date: Mon, 15 Sep 2003 15:44:39 -0700

Ack, that is what I hate about upper level protocols defining lower
level protocol behaviors...

Ok, first by making "the new cypher on the block" the only MUST
implement we get into a situation where AES might become broken, and
therefor we have a problem.

Yes 3des isn't as nice (for many reasons) but I know that I have better
than 90 bits of security with it.  With only 4-5 years of research
agains AES, I am not sure about that (yes I have read B Schneier's work
on cracking AES - don't think it is practical, but I am not enough of a
mathematician to prove it).

Security protocols go out of their way to prove interoperation, IPsec,
TLS, etc. if it turns out that we can not just use these lower layer
protocols intelligently -- why have we bothered to define them

Bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Monday, September 15, 2003 12:41 PM
To: [email-masked]
Subject: [Rserpool] TLS cipersuites for Rserpool

I am including the SIP RFC 3261 security section as an example. In the
SIP specification there is the following text:

PU <----> ENRP Server
PE <----> ENRP Server

I recommend Rserpool security text as follows (for ENRP and ASAP
security
sections):

The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a
minimum
by implementers of TLS for Rserpool.   For purposes of backwards
compatibility, ENRP SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA.
Implementers MAY also support any other ciphersuite.

I'll get Eric Rescorla's advice about this TLS cipher suite being the
right one to make mandatory to support and also his take on backward
compatibility.  We might not need this in ENRP assuming that everyone
will write new code for Rserpool infrastructure.

Any comments?

-- maureen

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

---

From: "bill" <[email-masked]>
Date: Mon, 15 Sep 2003 15:44:39 -0700

Bill

-----Original Message-----

PU <----> ENRP Server
PE <----> ENRP Server

Any comments?

-- maureen

---

From: Melinda Shore <[email-masked]>
Date: Tue, 16 Sep 2003 08:43:49 -0400

> therefor we have a problem.

This has been discussed fairly extensively in saag, and the
consensus was that AES should be mandatory-to-implement in
new protocols and what to do about 3DES was an open question.

A bigger problem than the possibility of a cipher being
compromised, I think, is that when you've got multiple ciphers
providing different degrees of protection you've got the
possibility of a bid-down attack, which is a protocol attack
and frankly more accessible.  If more than one cipher is
to be specified we need to be explicit about how they're
requested/signaled and to make sure that it's resilient against
that particular type of attack.

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Tue, 16 Sep 2003 08:43:49 -0400

Melinda

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 16 Sep 2003 14:31:41 -0500

I guess this must have been talked about by others but I am just not
well informed about the answer - will there be any IPR ramifications
when we say RSERPOOL MUST use certain ciphersuite? My impression is that
a lot of ciphers contain IPR. If that is the case, does the "MUST" imply
that RSERPOOL can not be implemented without tripping over some cipher
IPR?

regards,
-Qiaobing

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 16 Sep 2003 14:31:41 -0500

regards,
-Qiaobing