Re: Comments on Mandatory Ciphers and a Proposal

[Ned Freed <Ned.Freed@xxxxxxxxxxxx>]

> > There will surely be uses of TLS for which 3DES isn't considered to be of
> > sufficient strength, and there may even be uses of TLS for which DES40 is
> > considered adequate.  So there's no problem with a particular application
> > protocol using TLS as a component, and specifying its own mandantory
> > ciphersuites, and we should expect this from time to time.

> > And yet, TLS should in most cases be a layer that can be reused and
> > shared by different applications on the same platform.  So it does
> > make sense to specify a mandantory ciphersuite set for TLS, and not
> > only on a per-application basis.

> So, what you're saying is that we say it's "MUST implement", but hey, if
> you don't feel like, you're free not to.

Of course you are free to do whatever you want in your implementation. The IETF
doesn't pass laws banning stupid behavior, after all. All the IETF does is
establish a set of standards. Whether or not you follow them is your business.

> Can I define my application as
> "Tom's implementation of TLS" and say that for that "application" that
> nothing is mandatory?

Sure you could. You can define whatever rules you like for applications
developed outside of the IETF. What you cannot do, however, is then claim that
this application profile of TLS conforms to IETF standards. (Actualy you can
claim this but you'd be lying.) Why? Because any such profile is going to have
some set of mandatory ciphersuites in it to guarantee interoperability, and you
just said you your profile doesn't have any such set.

> What exactly does "MUST implement" mean if it
> doesn't mean that you must implement it?

This is ludicrous. The IETF doesn't have an enforcment arm. You're not going to
get kneecapped by some IETF-sanctioned thug because you didn't implement a
mandatory part of some IETF specification and them claimed TLS compliance. What
will happen, however, is when your implementation fails to interoperate with
someone else's, and that someone else points at the IETF specification and
says, "See, I implemented the mandatory suite and you didn't and thus the
reason why we don't interoperate is because you're not in compliance with the
specifications for this application", your cusomter will dump your product,
demand a refund, and never buy from you again. And believe me, this really can
happen. I've seen sites shitcan software purchases in the million dollar range,
from very large software vendors, and in at least one case where there wasn't
any hope of getting a refund (tax dollars too, sigh), over exactly this sort of
issue.

> This is why I think SHOULD is the right way to go.  Anything else is too
> restrictive to be reasonable, and dilutes the integrity of the IETF
> standardization process.

I'm afraid you have this exactly backwards. The process is strengthened
by having clear, crisp specifications with guaranteed interoperability between
conforming implementations. The process turns into mush when it allows
a specification through that could result in compliant but noninteroperable
implementations.

				Ned