Re: draft agenda for San Jose meeting

At 11:17 AM -0800 12/2/96, Phil Karlton wrote:
>> From Christopher Allen <ChristopherA@consensus.com>
>
>> The short outline of "tls-changes" is:
>>
>>         1. MAC algorithm
>>         2. MAC contents
>>         3. Block padding
>>         4. Message order standardization
>>         5. Certificate chain contents
>>         6. The no_certificate alert
>>         7. Additional alerts
>>         8. Seperation of Record and Handshake layers
>>         9. Additional Record Protocol clients
>
>I strongly recommend that these be separated into 2 parts: those that
>force a change the current protocol (bits on the wire), and those that
>are clarifications of current practice.
>
>In particular points 1., 2., and 6. above would make all current
>implementations non-conforming. Do we have examples of interoperability
>between the proposed protocol and existing implementations? Would the
>version number be rolled forward?
>
>I suspect that those at the meeting will want to treat these proposals
>independently.

It was my understanding that the TLS working group has reached consensus
that we intended to standardize a new protocol based on SSL. I have always
taken this to mean that this would, in fact, be a new protocol, not just an
IETF rubber-stamp of a Netscape protocol. As such, I believe we've already
decided that changing the bits on the wire is within our intent. Certainly
issues like standardizing the MAC have always been discussed as an obvious,
simple, and reasonable step for the SSL to TLS transition

Also, I believe that items 3, 4, 9, and maybe 7 also imply changes to the
acceptable bits on the wire in the SSL protocol, because it's my belief
that cryptographic protocols must wherever possible check to make sure that
the other side is conformant, because a failure to conform may cause a
security failure which would otherwise be undetected. As such, I believe
that a conformant TLS implementation (if the above proposals were adopted)
would:
  - Check to make sure blocks are padded correctly
  - Ensure that messages arrived in the prescribed order
  - Not accept unknown record types or alerts.

In addition, I believe number 5 requires a change to the bits on the wire
because it continues to be my stance that the SSL protocol as standardized
requires complete certificate chains to be transmitted, regardless of
actual implementation behavior or revisionist modifications to the standard
document. As such, I believe that to transmit partial certificate chains
(as described in proposal item 5) is to be incompliant with the SSL 3.0
protocol (although you'll happily interoperate with many SSL 3.0
implementations).

In summary, I believe it is the charter and intent of the TLS working group
to standardize a protocol which involves changes to the bits on the wire
and that all the proposals above except for number 8 describe some change
to the legal and compliant bits on the wire. (Although some SSL
implementations may be flexible enough to allow communication with TLS
implementation on some items.)

Of course, in my role as editor I'm more than willing to describe in the
standard whatever the consensus of the working group is, even if it is
simply to standardize the SSL protocol (which is what the current contents
of the TLS internet draft is intended to represent).

 - Tim

Tim Dierks - timd@consensus.com - www.consensus.com
     Software Haruspex - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite

Received on Tuesday, 3 December 1996 04:02:57 UTC