[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on Mandatory Ciphers and a Proposal
Tom and all,
Tom Weinstein wrote:
>
> Keith Moore wrote:
> >
> > One can make a case that "Bare TLS" is much like "Bare IPv4". Like
> > IP, TLS is a generic layer that can be reused in many applications,
> > each with different requirements, and therefore should not be
> > over-constrained. Following this argument, either there should be no
> > required ciphersuites, or perhaps the only required ciphersuite should
> > be "null authentication, null encryption" (so that an application can
> > recover gracefully from a failure to negotiate something better).
>
> 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. 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.
I agree here with Tom. This is one "Fallback" possition that could
be considered. But I would add, not the only (Review back on this
thread
for details).
>
> >> 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.
> >
> > Depends on what you mean by "you". You as an individual can use TLS
> > however you want with your own protocols. And nobody is going to try
> > to stop you from adding a TLS layer to a standard protocol, for your
> > own private purposes, if you want to.
> >
> > But if you add a TLS layer to a standard protocol, and don't include
> > the mandantory ciphersuites for use of TLS with that protocol, and
> > claim to your customers that your implementation conforms to the
> > standards -- that's misleading and perhaps even dangerous. It might
> > not provide adequate security for that application, and it might not
> > interoperate with other implementations -- including those that follow
> > the standard for using TLS with that application.
>
> Okay, but I have to wonder what you consider a standard protocol. Do
> you
> mean IETF standards, or are other standards okay? 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? 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 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?
>
> > Looking at all this, it's probably inappropriate for any application
> > to claim that it conforms to the TLS spec -- it should instead claim
> > conformance to a profile of TLS for use with that application.
>
> 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".
>
> --
> What is appropriate for the master is not appropriate| Tom Weinstein
> for the novice. You must understand Tao before | tomw@xxxxxxxxxxxx
> transcending structure. -- The Tao of Programming |
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