Re: Comments on Mandatory Ciphers and a Proposal

[Keith Moore <moore@xxxxxxxxxx>]

> > > > Nope.  It's okay for a feature to be a SHOULD if failure to implement
> > > > that feature doesn't compromise interoperability.
> > >
> > >   That decision should be left up to those implimentors doint the
> > > inplimentation.
> > 
> > It *is* left up to the implementor.  But if the implementor doesn't
> > include the mandantory ciphersuites specified for that application,
> > then the implementation isn't compliant with the specification.
> > Period.
> 
>   Ok.  I guess I wasn't very clear on my comment here, so I will try to
> clear it up a bit.  NO application SHOULD be PREDICATED to ANY
> particular cipher suite.  That is a choice situation, not a MANDITORY 
> one. 

I'm not sure what you mean here, but I'll restate myself more clearly:

Every application that (a) needs security and (b) uses TLS for security
must define a mandantory set of ciphersuites.  Otherwise, we could have
a situation where two implementations didn't have a common ciphersuite
that was adequate to the needs of the application.

The definition of mandantory ciphersuites for a particular application
can either be by reference to the TLS spec, or by specifying a different
set of ciphersuites specifically for that application.

Note that an application may have certain minimum security needs,
and a user of an application may have different security needs.
To be compliant with the spec, any implementation of that application 
must be able to provide the minimum security needs.  But the "user"
(say, the administrator of a web server) should be able to adjust
the application according to the user's needs -- either to increase
or decrease the level of security required. 


>   The reason is pretty simple really.  If an implimentor does not
> choose to use teh cipher suite that is stated as MANDITORY, than
> he/she should have a choice as to which cipher suites they desire.

What you've said in essense if that if someone chooses, they should
be able to make a choice.  That's like saying X is X.

> And not be required to impliment ANY MANDITORY cipher suite at all.
> This is too limiting and not benificial to interoperability at all
> Period.

You haven't said a single thing in support of your argument.


> > So that any two implementations that are written to conform to the
> > spec, will interoperate.  As long as this is not the case for TLS,
> > the TLS specification is incomplete, and will not go forward on
> > the standards track.
> 
>   I don't see this as necessary as part of the standards track.  JeffS,
> doesn't either and stated such.  

Ultimately, IESG is responsible for making such decisions.
IESG did deem it necessary to have mandantory ciphersuites.

Some have argued that the market will force TLS implementations to
be interoperable.   But this is also a circular argument.  
No product that claims to implement TLS, but doesn't interoperate 
with other TLS implementations, is likely to stay around for very long.  
Left to itself, the market forces interoperability by making it so 
difficult for anyone to implement a product, that it's out of reach
of anyone without substantial resources.

IETF doesn't work that way.  IETF acheives interoperability by writing
clear specifications, making them publically available, and whenever
possible and appropriate, using technology that is available to anyone.
IETF's goal is not just interoperability, it also wants a level playing
field.


> It seems to me that this by definition
> limits interoperability rather than provides for it.

I suppose it depends on how you define interoperability.

I want to make it as easy as possible to build a TLS implementation,
such that any two TLS implementations provide adequate security for the
services that want to use it -- which is to say, most of the applications
level protocols we have today.

If two TLS implementations can't agree on a common ciphersuite,
that's not what I would call interoperation.  If two TLS implementations
can't negotiate a ciphersuite that provides adequate security for the
application, that's not interoperation either. 


> > Every standards-track application protocol must be completely specified.
> > If the application needs security, and uses TLS, there must be
> > mandantory ciphersuites specified for that application.  The only
> > question remaining is whether TLS itself needs to specify mandantory
> > ciphersuites, and allow an application protocol to simply reference
> > the mandantory ciphersuites chosen by TLS.
> 
>   This is not what I understand the IESG statment to say.  SO I can now
> see where we have some diffrences.

I'm speaking for myself here, not IESG.  But this is how I see things,
and it does reflect how I will cast my ballot as an IESG member.
I'm willing to consider counter-arguments, but so far I haven't seen
any argument that is even close to persuasive.


> > > > It's fine with me if the 40bit ciphersuites are in the "SHOULD
> > > > implement" category, as long as the DH/DSS/3DES ciphersuit is "MUST
> > > > implement".
> > >
> > >   Not ture completly.  if you add the DH/DSS/3DES ciphersuite as one
> > > of the should impliment group, than the implimentor can decide depending
> > > on the needs which of the cipher suites (possibly multipul), to be
> > > implimented or a selection wizard could be used for multipul
> > > applications to accomplish this gole without the need or requirnment
> > > for a MANDITORY cipher suite to be implimented.
> > 
> > Nope.  That doesn't satisfy the interoperability requirement.
> 
>   SUre does.  And if you think it doesn't, why doesn't it?

A spec for protocol FOO doesn't require any mandantory ciphersuites.
Implementor A of FOO chooses to implement ciphersuites P, Q, and R.
Implementor B of FOO chooses to implement ciphersuites W, X, and Y.
Both implementations follow the FOO specs to the letter, but they
can't interoperate.

Keith