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@novell.com]
> Sent: Monday, December 08, 1997 10:46 PM
> To: cmanros@cp10.es.xerox.com; moore@cs.utk.edu;
> rturner@sharplabs.com
> Cc: ipp@pwg.org; Harald.T.Alvestrand@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@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?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>