[ogsa-wg] secure channel profile explanatory ciphersuite statements

[Andreas Savva]

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