IPP Mail Archive: RE: IPP> Re: Area Directors' comments on IPP

RE: IPP> Re: Area Directors' comments on IPP

Scott Isaacson (SISAACSON@novell.com)
Mon, 08 Dec 1997 23:45:56 -0700

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?