I wrote the TLS requirement based on the availability of
TLS as a proposed standard. And like Scott has pointed
out, I did not mention SSL3 because of comments I
received on the DL and from others about referencing
something like SSL3 that is not somehow on the
standards track.
I guess what I'm proposing is that we include an
informative appendix (non-normative) that talks about
how to interoperate in "legacy" SSL3 environments. This
is exactly how its done in the TLS 1.0 document as well.
Randy
> -----Original Message-----
> From: Scott Isaacson [SMTP:SISAACSON at novell.com]
> Sent: Monday, December 08, 1997 10:46 PM
> To: cmanros at cp10.es.xerox.com; moore at cs.utk.edu;
>rturner at sharplabs.com> Cc: ipp at pwg.org; Harald.T.Alvestrand at uninett.no> Subject: RE: IPP> Re: Area Directors' comments on IPP
>> Randy and all,
>> To be perfectly clear, let's review some of the language that has been
> written down (both in the last call I-D and in emails since then).
>> >>> "Turner, Randy" <rturner at sharplabs.com> 12/08 9:33 PM >>>
>>> > The problem with not mentioning SSL3 as allowable in our
> > specification is that, until TLS becomes available, there will
> > be no interoperable implementations of IPP for IPP servers
> > implemented as CGI behind generic HTTP servers.
>> The security text that Randy wrote during the WG final comment period
> does
> not metion SSL3 at all. Does it need to? I beleive that the I-D used
> to
> say that SSL3 might be used by implementers however such an product
> would
> NOT be compliant. It was just as statement about the realities of
> deploying
> IPP over existing (now, today) infrastructure.
>> > And thats assuming that all the server installed base upgrade
> > when these TLS servers become available (which is unlikely).
> > I'm open to other wording in the spec, but we need to
> > document that SSL3 servers CAN interoperate with clients
> > that implement TLS, and vice versa.
>> The text that Randy proposes is:
>> "Within the context of this document, a "secure" implementation is one
> that
> utilizes a transport layer that supports Transport Layer Security
> (TLS)
> Version 1.0."
>> > And I totally agree that we need to try to meet our security
> > requirements without mandating encumbered security
> > mechanisms. To this end, some combination MD5,
> > Diffie-Hellman, and Triple-DES should give us a reasonable
> > level of security.
> > I don't feel that these technologies place an undue
> > burden on simple IPP services since we have agreed that
> > "secure" IPP clients and servers are optional.
>> Randy has written the following proposed text to support the idea of
> "if
> security is implemented, it MUST be TSL":
>> "Since the security levels or the specific threats that any given IPP
> system
> administrator may be concerned with cannot be anticipated, IPP MUST be
> capable of operating with different security mechanisms and security
> policies as required by the individual installation. Security policies
> might
> vary from very strong, to very weak, to none at all, and corresponding
> security mechanisms will be required. TLS Version 1.0 supports the
> type of
> negotiated levels of security required by most, if not all, potential
> IPP
> environments. IPP environments that require no security can elect to
> deploy
> IPP implementations that do not utilize the optional TLS security
> mechanisms."
>> Keith and Harald, is this acceptable?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>