Re: IPP> possible compromise?

[[e-mail] (Ira Mcdonald x10962)]

Hi Keith and Harry,

I think it's useful to note that even LDAPv3 has recently been
permitted to publish standards track RFCs WITHOUT any security
mechanism (and a rather naive note that suggests read-only
implementations).

I maintain that even a read-only implementation of LDAPv3 without
any security (for read) is a good deal more dangerous in the
business liability and exposure sense that an implementation
of IPP without any security in some printers is.

Cheers,
- Ira McDonald (High North Inc)
------------------------------------------------------------------------
[Keith and Harry's notes]
>From [e-mail] Wed Jul 15 12:25:40 1998
Return-Path: <[e-mail]>
Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1)
	id AA02665; Wed, 15 Jul 98 12:25:39 EDT
Received: from alpha.xerox.com by zombi (4.1/SMI-4.1)
	id AA15090; Wed, 15 Jul 98 12:18:22 EDT
Received: from lists.underscore.com ([199.125.85.30]) by alpha.xerox.com with SMTP id <55042(2)>; Wed, 15 Jul 1998 09:18:20 PDT
Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26143 for <[e-mail]>om>; Wed, 15 Jul 1998 12:14:37 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Jul 1998 12:10:38 -0400
Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA25365 for ipp-outgoing; Wed, 15 Jul 1998 12:07:28 -0400 (EDT)
Message-Id: <[e-mail]>
X-Uri: http://www.cs.utk.edu/~moore/
From: Keith Moore <[e-mail]>
To: Harry Lewis <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: IPP> possible compromise? 
In-Reply-To: Your message of "Wed, 15 Jul 1998 11:28:58 EDT."
             <5030050015552513000002L532*@MHS> 
Date: Wed, 15 Jul 1998 09:07:05 PDT
Sender: [e-mail]
Status: R

> Keith, I am trying very hard to follow this discussion to some form =
> of bedrock.  I'm not so adamant about the URL scheme... as long as 
> I can base my initial implementation on existing, off-the-shelf HTTP 
> servers, which I think we have safely agreed upon.
> 
> What I do need, however, is a timely end to the development process 
> for this standards specification. I suspect you would agree - none of 
> us have inexhaustible resources.
> 
> To this end, security appears to be a real "monkey wrench". Your 
> statement represents a basic "open loop" in my estimation.
> 
> It is insufficient, at this point, to be in the position of taking a 
> proposal to the IESG which we know will fail to ratify and which is 
> completely "Catch22" in context. We can't have security because it's 
> not there yet... yet we can't use the security which is there. 
> Unless there is some certainty of a very near term resolution of 
> the security issue which will satisfy the IESG, I claim we MUST 
> focus (and adjust, if appropriate) the IPP effort on utilization 
> of a viable interim security method.

Harry,

I share your concern about the need for a timely end to the development
process.  

While I do have doubts about the viability of IPP security for some
of the scenarios that IPP has envisioned, I also recognize that my
expertise is limited in this area.  I would rather leave it to 
the security ADs to evaluate the adequacy of IPP security.  If it's 
okay with them, it will be okay with me.

Even if the security ADs share my concerns, I will push to get the
Proposed Standard versions of the IPP specifications published quickly 
and with as few changes as possible -- perhaps with some sort of
disclaimer about the limitations of the current security setup.  The 
vast majority of printing applications do not need a fully general 
security solution, and IPP should not be kept waiting until such a 
solution exists.  It may be that IPP needs additional work to 
define URL parameters and/or profiles for how TLS should be used 
in some of the scenarios, but even if this is necessary I believe 
that most of the work can be done in separate documents that aren't 
in the critical path for the main IPP set.

I am pushing for the IESG review to be complete by the end of July,
though there is some chance that the review will take two weeks
longer than that.  But I am hopeful that IESG can get the feedback to
IPP by end July, and complete IESG approval of any revisions before 
the Chicago IETF.

Keith