Subject: Re: IPP> Use of SSL3 Framing????

From: Roger K Debry <[email-masked]>
Date: Thu, 6 Nov 1997 10:23:01 -0500

Randy wrote:

>SSL3 allows security parameters to be negotiated
>dynamically. All thats required is the support
>for SSL3 framing and session initialization.
>We're not absolutely requiring all of the
>cipher suites and authentication
>mechanisms the SSL3 spec includes.

I'm always concerned when I see the phrase "all
"that's required is ..."

---

From: Harry Lewis <[email-masked]>
Date: Thu, 6 Nov 1997 13:15:02 -0500

Sorry... my message got truncated somehow...

>> MAKING every IPP printer behave in a secure fashion could be misleading
>
>I'm curious why this would be misleading...

What I tried to say is that if the data is sensitive enough to require a
secure socket, it's likely the printer should also be, physically, in a secure
area. If every IPP printer must support HTTPS (for example) then one could
easily be duped into thinking they were engaged in "secure printing" when,
indeed, they are not.

Harry Lewis - IBM Printing Systems

---

From: "Wagner, William" <[email-masked]>
Date: Thu, 6 Nov 1997 13:39:09 -0500

I appreciate Carl-Uno's clarification of the security issue, and for
expressing the rational for the IPP doing something of an about face at
this late date. I also am disturbed by what appears to be a new
requirement and am awaiting a more detailed analysis of the impact to
implementation and schedules.  I would much prefer keeping  Secure IPP
as an option, as was established in Atlanta.

I know that some feel that IPP is intended only for Internet (as
distinguished from intranet) printing; but I would suggest that IPP only
makes sense as a common IP printing service, indeed supplanting LPD and
the myriad of proprietary TCP/IP print services. It we structure IPP as
intended primarily for cross firewall communications, we are severely
limiting its applicability.
Considering that (to pick out a number), something in excess of 95% of
IP Printing will be within a local environment, coming up with a
printing protocol aimed at less then 5% of the traffic seems
inefficient. 

Also, there are those who intend  the IPP server to be implemented in a
stand-alone HTTP server; mandating some degree of security may have
little impact upon them since the servers are intended for non-local
communication.

However, a large potential class of IPP user would be constituted of the
smaller network printer which for cost effectiveness has an embedded IPP
capability. For this potentially predominant product class, security of
this sort is superfluous. To identify a mechanism for secure IPP is
necessary; to make it mandatory  so as to burden the majority of the
units with something needed by relatively few does not seem reasonable
(although it perhaps smacks of the IETF rational that does not recognize
the intranet environment).

Also, as is pointed out, requiring SSL3 makes little sense since it is
an interim solution. Requiring TLS is unfeasible since it is not final.
Mandating a capability which is still in such flux does not seem
appropriate to getting IPP up and running. We should again consider
whether our objective is just to create a specification,  or to enable
the inclusion of a new, necessary and viable printing service in printer
products.

Bill Wagner

DPI/Osicom

---

From: Scott Isaacson <[email-masked]>
Date: Thu, 06 Nov 1997 14:14:23 -0700

>>> "Wagner, William" <[email-masked]> 11/06 11:39 AM >>>
> an interim solution.

It is not an interim solution in that TSL accepts the fact that SSL3 is in
place
today and it is deployed almost everywhere
and TSL shows a way to accept SSL3 as a compatibility mode.  The way
to get to TSL is through SSL3.  SSL3 is really the only thing that any
product
would use if deployed in the next few months anyway. 

Scott

---

From: Scott Isaacson <[email-masked]>
Date: Thu, 06 Nov 1997 14:27:20 -0700

>>> "Xavier D. Riley" <[email-masked]> 11/06 9:53 AM >>>

> I would speculate that most SSL3 web server implementations don't support
> configuring the Cipher Suite to be SSL_NULL_NULL_WITH_NULL_NULL.

Good point, however I am very interested in why you "speculate" that?
Tried it and it didn't work?  Gut feel?  The product documentation says so? 
Which web servers?   

Scott

My vote (today) is to keep secure and non-secure entries separate for 
IPP 1.0 and when TLS is approved and deployed in existing off the shelf 
web servers, we specify the use of it in a later version of IPP.  I will 
hold my final vote until I read the document you plan to release this week.

The advertisement of non-secure and secure IPP print systems can occur
outside
the IPP specification by the simple use of a Web page or LDAP server
advertising 
both print system URLs. I would venture to say that most implementations
would 
either be configured to be non-secure or secure, not both.

Non-Secure IPP Print Systems = No Authentication
                               Basic Authentication
                               Digest Access Authentication.

Secure IPP Print Systems = Channel level security (i.e. SSL3)

______________________________________________________________________
Xavier Riley                     
Xerox Corp.                      
Corp. Research & Tech.           Voice: 310-333-8329 / 8*823-8329   
701 S. Aviation Blvd ESAE-231    Fax: 310-333-6618 / 8*823-6618
El Segundo, California 90245     Email: [email-masked] 
______________________________________________________________________

---

From: "Turner, Randy" <[email-masked]>
Date: Thu, 6 Nov 1997 14:11:05 -0800

Let me emphasize the word "de facto", because I can't think of any HTTP
server shipping today that doesn't support HTTPS (Netscape Enterprise
Server, Microsoft IIS, Apache). The question was whether or not there is
some requirement, and there is no STANDARD requirement that HTTP servers
support
SSL3, but there is a very strong MARKET requirement for this type of
support.

Randy

> -----Original Message-----
> From:	Larry Masinter [SMTP:[email-masked]]
> Sent:	Thursday, November 06, 1997 2:07 PM
> To:	Randy Turner
> Cc:	Harry Lewis; [email-masked]
> Subject:	Re: IPP> Use of SSL3 Framing????
> 
> > They are required by de facto, not by a pure standard, to support
> HTTPS
> > because no commercial vendor of HTTP servers would introduce a
> server
> > incapable of providing the capability for internet commerce.
> 
> This is utterly false. Not all HTTP servers are required to support
> Internet
> commerce. 
> -- 
> http://www.parc.xerox.com/masinter

---

From: Carl-Uno Manros <[email-masked]>
Date: Thu, 6 Nov 1997 14:49:29 PST

Randy,

You seem to think only about web server vendors. There are a number of
other HTTP implementations, in particular for embedding in devices (such as
printers) that are counting every bit they put in.

Carl-Uno

>> This is utterly false. Not all HTTP servers are required to support
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]