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

From: "Turner, Randy" <[email-masked]>
Date: Mon, 8 Dec 1997 20:33:45 -0800

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.

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.

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

> -----Original Message-----
> From:	Keith Moore [SMTP:[email-masked]]
> Sent:	Monday, December 08, 1997 10:23 AM
> To:	Carl-Uno Manros
> Cc:	[email-masked]; [email-masked]; [email-masked]
> Subject:	IPP> Re: Area Directors' comments on IPP 
> 
> > 1) Support for SSL3 in TLS. Harald and Keith wanted to make sure
> that our
> > specs say that we MUST support the mandatory features that are
> minimum
> > requirements for TLS, such as the cypher suite. 
> 
> 1. IESG has not allowed other groups to reference SSL, and it unlikely
> that an exception would be made for IPP.  If IPP uses SSL-like
> technology, the reference should be to the TLS RFC.
> 
> 2. If IPP specifies TLS authentication, IPP must either implicitly use
> the mandatory ciphersuite from the TLS spec, or specify at least one
> mandatory TLS ciphersuite.
> 
> 3. It will be very difficult for IPP to convince IESG to accept any
> mandatory TLS ciphersuite that uses encumbered algorithms, especially
> given that adequate unencumbered algorithms seem to be available.
> 
> Suggestion: specify MUST implement ciphersuite
> TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, and MAY (or SHOULD?) implement one
> or more of the ciphersuites commonly used with SSL3.
> 
> Keith
>

---

From: Scott Isaacson <[email-masked]>
Date: 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" <[email-masked]> 12/08 9:33 PM >>>

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

> 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."

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

---

From: "Turner, Randy" <[email-masked]>
Date: Tue, 9 Dec 1997 05:29:29 -0800

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

> From:	Scott Isaacson [SMTP:[email-masked]]
> Sent:	Monday, December 08, 1997 10:46 PM
> To:	[email-masked]; [email-masked];
> [email-masked]
> Cc:	[email-masked]; [email-masked]
> Subject:	RE: IPP> Re: Area Directors' comments on IPP
> 
> Randy and all,
>

---

From: Carl-Uno Manros <[email-masked]>
Date: Tue, 9 Dec 1997 05:49:58 PST

Randy,

We already have that as an Appendix in the Protocol Specification draft. We
should just check if we need to do any further edits to the Appendix. Check
Bob's latest draft.

Carl-Uno

>> Keith and Harald, is this acceptable?
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]