Re: making progress

David,

  Please read below your comments.

David P. Kemp wrote:
> 
> > From: david.brownell@Eng.Sun.COM (David Brownell - JavaSoft)
> >
> > I haven't said anything about Win's "option #2", namely producing an I-D
> > covering the TLS record layer (compatible with SSLv3), and presumably the
> > basic encoding rules (XDR-ish), and separating the handshaking into two or
> > more documents.  (SSLv3 compatible, shared key, and I predict debate re
> > GSS-API, ISA/KMP, etc flavors.  Which is why I prefer option #1.)
> >
> > This seems a reasonable thing from a technical standpoint, and I'll just
> > flag my concern that it not delay concurrent progress on the rest of the
> > protocol.
> 
> Creating a document that codifies existing practice (i.e. SSL V3.0, with
> technical clarifications but no new features) should be doable by December,
> and I fully support the effort by Consensus and other developers with
> actual implementation experience to do so.

  David, I would be happy to assist here in that I do have some actual
implimentation experiance.  Let me know.
> 
> I believe that that document should take the form of an Informational
> (as opposed to Standards Track) RFC and should be called SSL 3.0 instead
> of TLS 1.0, because my vision of TLS as an Internet Standard is somewhat
> different than SSL as it currently exists.  But I fully agree that our
> credibility is on the line if we can't even produce a document that defines
> existing practice, having had 9 months from the date of the SSL 3.0 draft
> and 6 months from Montreal to do so.

  Got a problem here, Dave.  Two diffrent TLS standards for two diffrent 
"Flavors" of TLS is somewhat too confusing in my opinion.
> 
> >  If we make the HMAC in the TLS record layer cover the record
> > header, that would be a positive change!  (An SSL 3.1 could do that too.)
> 
> The HMAC does cover the record header, except for the deprecated record
> version field (as opposed to the Handshake version field, which is the one
> that counts.)  The record format is a bit ideosyncratic though, and defining
> a cleaner one independently of the handshake exchange is one reason for
> having separate documents.
> 
> (As an aside, the Record layer changes I'd like to see are:
> 
>  1. Make the HMAC calculation conform to the IPSEC HMAC - xor the
>  padding instead of concatenating it.  I don't know Hugo's rationale
>  for changing the definition, and I don't know if there are any problems
>  with the concatenated-padding HMAC, but absent any rationale to the
>  contrary, TLS should use the standard technique instead of remaining
>  gratuitously different.
>  "HMAC: Keyed-Hashing for Message Authentication" was submitted to the
>  IESG as an Informational RFC in August.  It has not appeared as an
>  official RFC yet, but was published on the IPSEC mailing list on 24
>  October.
> 
>  2. Either clarify the meaning of the Record version number, or eliminate
>  it.  That field appears to be a useless holdover from SSL V2 (especially
>  since it was conspicuously omitted from the MAC calculation).  If there
>  is a need for a Record version distinct from the Handshake protocol
>  version, then it should be covered by the MAC. (Conventional wisdom
>  is that protocols should always have a version number, so I guess the
>  record layer should too, even if it remains 1 forever. But there's no
>  need to waste two bytes on it when one byte is more than sufficient :-)
> 
> I don't want to discuss the merits of these changes now - this is just
> an example of why a modular document structure is preferable to a
> monolithic document.  The appropriate time to discuss protocol changes
> is after SSL 3.0 is published.)
> 
> > I'm not opposed to shared key support, but I've not seen a proposal that's
> > well enough defined that I could support it.  For example, one that
> > supports both low security passphrases and higher security Kerberos
> > options, with clear operational distinctions like SSLv3 "cipher suite"
> > model.  Promoting "islands of interoperation" is a bad thing IMHO, and
> > without a better shared key proposal that's where we'd be heading.
> 
> It is generally accepted IETF practice to categorize mechanisms as
> "REQUIRED", "RECOMMENDED", and "OPTIONAL".  All protocols must define
> at least one REQUIRED mechanism, to enable interoperability among all
> conforming implementations. For TLS client authentication, I fully
> expect that support for client certs will be REQUIRED.

  I hope that  client certs will be REQUIRED.  But I concur I have not
seen
any clear perposal to that effect.  Somewhat puzzeling I think,
especially
sience alot of discussion was done on that subject.
> 
> But defining OPTIONAL mechanisms within the standard at least expands
> the "islands of interoperation" into "continents" :-).  If there is
> a market need, it will be satisfied, either through vendor-proprietary
> means or through standardization.  I prefer the latter, particularly
> since some vendor-proprietary shared-key-auth mechanisms might not be
> as high quality as the proposed challenge/response mechanism.

  Well if I read you right here, I have some problems with defining
"OPTIONAL" mechanisms as part of any standard as IETF currently defines
"OPTIONAL".  It is either required or not. Otherwise the "Standard" part
leaves some meaning behind form a "Standards"  point of view.  But that
is
a whole diffrent discussion. 
> 
> Since the application already needs to interact with the TLS protocol
> to do shared-key-auth, it already knows whether it's dealing with
> "SKA-16" (user-chosen passphrases) or "SKA-128" (128 bit true random
> secret keys).  But if you can articulate why a Quality of Protection
> field might be needed within the protocol, I'm sure such a field could be
> easily added to the proposal.

  Well, I think this needs to be defind and decided upon.  Not just an
addition to a perposed standard.

-- 
Jeffrey A. Williams
SR.Internet Network Eng. 
CEO., IEG., INC.,  Representing PDS .Ltd.
Web: http://www.pds-link.com 
Phone: 214-793-7445 (Direct Line)
Director of Network Eng. and Development IEG. INC.

Received on Monday, 28 October 1996 11:39:06 UTC