[IPP] Initial draft of IPPS URI Scheme (25 August 2010)

[IPP] Initial draft of IPPS URI Scheme (25 August 2010)

Michael Sweet msweet at apple.com
Mon Aug 30 23:43:51 UTC 2010


On Aug 30, 2010, at 2:41 PM, Ira McDonald wrote:
> Hi,
> 
> I agree with Mike.  If you support "ipps:" on an IPP Printer object
> and also support "ipp:", then you MUST support HTTP Upgrade.
> 
> About encryption:
> 
> For many printing situations (emails, service messages, etc.) it's
> fine to send the data in cleartext over the enterprise network, VPN,
> or even public Internet - but you still want Data Integrity (i.e., secure 
> hashes of application PDUs in the TLS Record layer) - "print what
> you sent" - right?

In general, data injection/replacement isn't a real problem - aside from pranks, there is little to be gained at great cost, especially when most jobs are one-offs.

The real issues for secure printing environments are privacy/disclosure of print data and authentication and authorization of clients, servers, and services.  For example, when you print something on the MFD down the hall, are you actually talking to the MFD down the hall when you send the print job?  TLS provides a way to provide both privacy and authentication/authorization, but for environments where the network is already secured something as simple as Digest authentication with the MD5-session stuff may be sufficient to prevent man-in-the-middle attacks.

> 
> Cheers,
> - Ira
> 
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Co-Chair - TCG Hardcopy WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music/High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto:blueroofmusic at gmail.com
> winter:
>   579 Park Place  Saline, MI  48176
>   734-944-0094
> summer:
>   PO Box 221  Grand Marais, MI 49839
>   906-494-2434
> 
> 
> On Mon, Aug 30, 2010 at 5:34 PM, Michael Sweet <msweet at apple.com> wrote:
> On Aug 30, 2010, at 8:20 AM, Ira McDonald wrote:
>> ...
>> I do think we should RECOMMEND against the practice,
>> because it supplies ambiguous security to the IPP Printer
>> object.
> 
> FWIW, while it is certainly possible I think it would be better to simply require that printers supporting both ipp and ipps report the appropriate keywords for uri-security-supported (ssl3 and/or tls) along with mandatory support for HTTP Upgrade.  That would be consistent with our "message" since IPP/1.1 and gives us what we want on the standards side of things.
> 
> Whether a Printer allows clear-text connections when configured with SSL/TLS support is, IMHO, a site-specific policy outside the scope of IPP, and in particular HTTP Upgrade allows both the Client and Printer to enforce a particular policy dynamically.  Moreover, some communications channels may already be secured, making any transport-level encryption optional over those channels.
> 
> ________________________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 
> 
> 
> 
> 

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair





-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20100830/e6decd67/attachment-0001.html>


More information about the ipp mailing list