[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