secure channel profile explanatory ciphersuite statements
The Security Profile - Secure Channel (Sep 28 draft) has a set of statements, which elaborate on the compliance statements, along the lines of "Ciphersuites listed in Table 3 in TLS-Guideline [TLS Guidelines] meet criteria of R0XXX." We discussed these statements last Thursday and it was stated that such statements are not intended to be normative. I took an action to rewrite the text to make it clearer that these are not normative statements. The problem I have after looking at the text again (incl the compliance statements) and also looking at the WS-I BSP is that it does not help people wishing to implement the Secure Channel profile if these statements are not normative and if they do not describe concretely which suites should be used (or not). Saying 'do not use known insecure suites' or 'only use secure ones' are motherhood statements. In any case they are not really testable which is one point of compliance statements. Also the WS-I BSP has some discussion and normative statements in sec.3.2 about TLS/SSL ciphersuites and since the Secure Channel states that it "extends the WS-I Basic Security Profile 1.0" I became unsure about the relation of the various compliance statements in the Secure Channel and the statements in the WS-I BSP is. In short, sorry, can't do. I am not a security person... ;-) Maybe we should discuss this issue again on the next call this Thursday. (Dave? Alan? Takuya? Frank!) Andreas
Andreas, I believe we should include some normative statements about cypher suites. I would suggest we pick one or possible two that are pretty universal and say the MUST be supported by the server side. Clients SHOULD use these. and both MAY us others, including ones not yet on the list. Thoughts? On 4 Oct 2006, at 03:18, Andreas Savva wrote:
The Security Profile - Secure Channel (Sep 28 draft) has a set of statements, which elaborate on the compliance statements, along the lines of "Ciphersuites listed in Table 3 in TLS-Guideline [TLS Guidelines] meet criteria of R0XXX." We discussed these statements last Thursday and it was stated that such statements are not intended to be normative. I took an action to rewrite the text to make it clearer that these are not normative statements.
The problem I have after looking at the text again (incl the compliance statements) and also looking at the WS-I BSP is that it does not help people wishing to implement the Secure Channel profile if these statements are not normative and if they do not describe concretely which suites should be used (or not). Saying 'do not use known insecure suites' or 'only use secure ones' are motherhood statements. In any case they are not really testable which is one point of compliance statements.
Also the WS-I BSP has some discussion and normative statements in sec.3.2 about TLS/SSL ciphersuites and since the Secure Channel states that it "extends the WS-I Basic Security Profile 1.0" I became unsure about the relation of the various compliance statements in the Secure Channel and the statements in the WS-I BSP is.
In short, sorry, can't do. I am not a security person... ;-)
Maybe we should discuss this issue again on the next call this Thursday. (Dave? Alan? Takuya? Frank!)
Andreas
-- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
-- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave, Andreas, I think this is the right path we are heading. David Snelling wrote:
Andreas,
I believe we should include some normative statements about cypher suites. I would suggest we pick one or possible two that are pretty universal and say the MUST be supported by the server side. Clients SHOULD use these. and both MAY us others, including ones not yet on the list.
I think this is overly restricted. While I agree that we should add a core set of cipher suites that MUST be supported, using MAY for the rest is too relaxing. I would have a SHOULD for them. Regarding cipher suites defining no encryption. We should still allow them as they serve important use cases, but we should not require implementations to support them. Regarding cipher suites that make use of weak methods. We should disallow them as they claim protection they actually do not provide, such as RSA export grade authentication, RC4 encryption, or MD2(?) message hashing. As a summary, we should add three sections to the profile and explain where we sourced the list of cipher suites from (was it the IETF? TLS specification?): a) A section with cipher suites that MUST be supported (strongest protection in all three aspects of a cipher suite) b) A section with Cipher suites that MUST NOT be supported c) A section stating that all the rest SHOULD be supported. We also should think of adding an expiry date to the profile to enable regular updates in case a security method is considered unsafe after the publication date of the profile (for example, SHA-1 was considered safe until very recently, but the discussions are still ongoing on this one). Thoughts? Cheers, Michel - -- Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com Fujitsu Laboratories of Europe +44 20 8606 4834 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFI4lSk0lMZTNKw4QRAtfmAJ9EbckQJTp+zHcrU8UPJkXwpHISFwCgxq3e Or9OMLoGeMHPR9m/0lBx9Lw= =P8eA -----END PGP SIGNATURE-----
Some comments inline: Michel Drescher wrote:
Dave, Andreas,
I think this is the right path we are heading.
David Snelling wrote:
Andreas,
I believe we should include some normative statements about cypher suites. I would suggest we pick one or possible two that are pretty universal and say the MUST be supported by the server side. Clients SHOULD use these. and both MAY us others, including ones not yet on the list.
I think this is overly restricted. While I agree that we should add a core set of cipher suites that MUST be supported, using MAY for the rest is too relaxing. I would have a SHOULD for them.
I agree with Dave's wording here. I think he's got it right when this is stated as a compliance statement.
Regarding cipher suites defining no encryption. We should still allow them as they serve important use cases, but we should not require implementations to support them.
Not sure, I think I have to see against which compliance statement this would apply.
Regarding cipher suites that make use of weak methods. We should disallow them as they claim protection they actually do not provide, such as RSA export grade authentication, RC4 encryption, or MD2(?) message hashing.
As a summary, we should add three sections to the profile and explain where we sourced the list of cipher suites from (was it the IETF? TLS specification?): a) A section with cipher suites that MUST be supported (strongest protection in all three aspects of a cipher suite) b) A section with Cipher suites that MUST NOT be supported c) A section stating that all the rest SHOULD be supported.
I think this is reasonable and is quite close to what the WS-I BSP 1.0 has done with sections on - Mandatory - Recommended - Discouraged - Prohibited And this comes back to the question I asked in the initial email and I hope that Takuya can answer. What is the relationship of the claims of the Secure Channel and the WS-I BSP claims (sections 3.2). Btw, I am looking at the Aug 2006 version of the WS-I BSP and not the one that Takuya has in the References which is one year older (Aug 2005).
We also should think of adding an expiry date to the profile to enable regular updates in case a security method is considered unsafe after the publication date of the profile (for example, SHA-1 was considered safe until very recently, but the discussions are still ongoing on this one).
An expiry date is probably a good idea for this kind of document. -- Andreas Savva Fujitsu Laboratories Ltd
participants (3)
-
Andreas Savva -
David Snelling -
Michel Drescher