IPP> Re: Area Directors' comments on IPP

IPP> Re: Area Directors' comments on IPP

IPP> Re: Area Directors' comments on IPP

Turner, Randy rturner at sharplabs.com
Tue Dec 9 08:29:29 EST 1997


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?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                                                       



More information about the Ipp mailing list