Re: Moving the TLS Process Forward

[Jeff Williams <jwkckid1@xxxxxxxxxxxxx>]

Christopher and all,

Christopher Allen wrote:
> 
> At 4:00 PM -0700 7/24/97, Keith Moore wrote:
> >But Internet standard application protocols that use TLS are going to
> >need "MUST implement" ciphersuites.
> 
> I think we have a process problem here, that requires a process solution.

  i one sense I agree. In another (Technical), i don't.  It seems
to me that there is a technical design problem here with respect
to what constitutes Interoperability and what does not.  You could
say that this is indeed a process problem.  I disagree strongly.
Especialy in light of the fact that there has been good arguments
on both sides of the MUST and SHOULD cariants of the ciphersuites
inclusion stiuation.  This is in my mind, not a process problem,
rather it is a design problem.
> 
> We are at an impasse -- there was rough consensus when the TLS draft was
> submitted to the IESG, and now that there has been a requirement passed
> down by the IESG to mandate MUST ciphersuites we have lost that consensus.
> In fact, if anything, I think the weight of what consensus we do have is
> against the IESG opinion here (or at least the IESG opinion as has been
> represented by Keith and Jeff.)

  Jeff who?  Me?  OR Jeff S. ?
> 
> Fundamentally, I think we have an architecture problem. There are those
> that believe that it should be security over interoperability -- following
> a sort of "cryptographers code". Then there are the protocol designers that
> emphasize their own "interoperability code".

  I agree here.  This is mainly a Design/Archtecture problem rather
than a process problem.  
> 
> The only position that had rough consensus (before and after the IESG
> remandment) is that higher level applications protocols may specify MUST
> ciphersuites, but the TLS spec itself should not.

  I think this is correect esentialy.
> 
> Thus, in order to move past this process SNAFU, I'd like to see that the
> IESG officially tell the TLS working group "you must put in MUST
> ciphersuites in the TLS spec". This request should be put in writing and
> appear in the next IESG minutes (as the previous "remanding" of the TLS
> document was apparently not official as there is nothing about TLS in the
> previous IESG minutes.)

  NO NO NO!  This is not going to solve anything here.  This is passing
the buck in a sense.  Best thing to do is fix the archtecture problem.
> 
> Given that official remandment by the IESG, we (the editors) will proceed
> with putting the MUST ciphersuites into the draft, and hopefully the draft
> can finally go RFC as a Proposed Standard by Munich.

  I am strongly against this approach.  DOes not solve the underlying
problem
at all.  It mearly puts it in a political mode, and therefore weakens
what TLS is all about in my mind.
> 
> Meanwhile, those of us that have an issue with this IESG decision can take
> the opportunity to pursue IAB appeal of that IESG mandate in that separate
> venue. If the appeal is granted, the changes can be applied to the TLS RFC
> when TLS goes from proposed standard to draft standard next year.

  This may be a idea that COULD work, but is not the BEST approach.  

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