Re: Comments on Mandatory Ciphers and a Proposal

[Jeff Williams <jwkckid1@xxxxxxxxxxxxx>]

Keith and all,

Keith Moore wrote:
> 
- snip -
> >
> > This is where we fundamentally disagree.  As Dan Simon explained so
> > eloquently, in a security protocol sometimes the right thing is to NOT
> > allow communication.
> 
> That's absolutely true...sometimes.  But for some applications that
> are going to use TLS, the right thing is to allow communication in
> degraded mode, and let the application act appropriately, either
> by issuing an error message, or refusing to grant certain privileges.
> Imagine an SMTP server which supports TLS...  if you can authenticate
> yourself to it, it will let you use the TURN command.  If you can't
> authenticate yourself to it, it will still let you send mail.

  Good point here.  I agree.  Degraded ins SOME cases is perferable
than NO COMMUNICATIONS.
> 
> > If there's no intersection between the two sets of
> > supported cipher suites, the correct "fallback" is to display an error
> > message stating that the application can't communicate because of a
> > mismatch of security policies.
> 
> Not in all cases, probably not even in most cases.  Applications that
> use TLS need to be aware that they're using TLS, and modify their
> behavior accordingly.  Applications have to implement security policy
> anyway, because there's a lot more to security policy that what
> the TLS layer can enforce by itself.

  Again I agree.  But shouldn't TLS be able to provide for nearly all
the possible ciphersuites that a security policy MAY be using as part of
that policy?
> 
- snip -
> >
> > Okay, but I have to wonder what you consider a standard protocol.  Do
> > you mean IETF standards, or are other standards okay?
> 
> IETF can make rules for itself, and suggestions for other standards
> bodies that use TLS.

  Ok, but this seems a bit weak to me.
> 
> > Does the standards
> > body that defined the basic standard also have to define the profile for
> > TLS when used with that protocol, or can some other standards body?
> 
> No.  But we try not to step on each others' toes.
> 
> > These may seem like silly questions, but I'm very serious, and I don't know
> > the answers.  I want to do the right thing, and I don't want to lie to
> > my customers.  What does "implements the TLS protocol" mean?
> 
> Here's a stab at an answer:
> 
> 1. The TLS RFC should specify a default set of ciphersuites to be used
> in the case where there is no specification for FOO+TLS, or if the spec
> for FOO+TLS doesn't override the defaults.
> 
> 2. The TLS RFC should state something like:
> 
> a. Because the default set of ciphersuites might not be appropriate,
> widespread deployment of a TLS-aware application in the absence of
> a standard specification for doing so, is discouraged.
> 
> Any application FOO which simply claims conformance to the TLS spec,
> rather than a spec specifically written for TLS+FOO, is assumed to
> support the mandantory ciphersuites in the TLS spec.  (though
> applications should always be able to have their security policy set
> to enable or disable any of the ciphersuites supported by their TLS layers.)
> 
> b. Anybody (not just IETF) who writes a spec for FOO+TLS, who doesn't
> think the default set of ciphersuites is appropriate, should specify
> a different set.   If that spec doesn't specify a different set of
> mandantory ciphersuites, the default set in the TLS RFC is assumed.
> 
> c. A TLS layer, as opposed to an application using TLS, should claim
> compliance to the TLS spec *and list the ciphersuites it supports*.
> 
> (overall, I find it much easier to specify what "compliant TLS-enabled
> FOO" means, than I do to specify what "compliant TLS implementation" means)

  I like this very much.  SOme additions could be made I think, but
overall very well put.

> 
> > Here's another case:  what if two different standards bodies standardize
> > the same protocol (such as PKIX is doing with X.509)?  Who gets to
> > decide what the profile is?
> 
> Anyone can define a profile.  Implementations should claim compliance
> to one or more particular profiles, e.g. RFC FOO or IS-XXXX-99 or X.###.
> That's the only way to be unambiguous.

  Very true.
> 
 -snip -
> >
> > This is a very subtle distinction, which is probably beyond most users.
> > And I guarantee that marketing will always say "TLS compliant" or
> > "implements TLS", rather than "conforms to the TLS profile for protocol
> > foo".
> 
> And that's the rub.  We want to make it difficult for marketing people
> to mislead people.  Of course, that's what they're best at :)

  Good policy.  They sure do.  >;)
> 
> We can't keep marketing people from claiming "compliance with TLS",
> but we can specify what "compliance with TLS" means.  And if we publish
> standards with titles like "Standard Profile for SMTP with TLS"
> we can at least hope that those RFCs will be referenced.

  Yes we can I suppose.  
> 
> Keith

Regards,
-- 
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java Development Eng.
Information Eng. Group. IEG. INC. 
Phone :913-294-2375 (v-office)
E-Mail jwkckid1@xxxxxxxxxxxxx