Thanks for your reply Mike!
To try to be more concise, should IPPIGv2 include Printer recommendations to prevent or stop an imprudent Client from sending “sensitive information” in the clear before the Printer can respond with a 426 Upgrade?
I do understand that HTTP/1.1 Expect isn’t required for an upgrade. If the Client included the HTTP/1.1 Expect header, the Printer could reply early with a 426 before the sensitive information hit the wire.
> It goes beyond TLS - some IPP operations may require authentication, others may not depending on the policy configured in the Printer. So Clients should always include the Expect header unless they know the Printer does not support it, and that allows the correct things to happen without leaking information the Server wants to be confidential based on its configuration.
Right! I was thinking about that as well this morning. Should there be yet another attribute like “ipp-operations-requiring-tls”? (Or if we really want to shoot down the rabbit hole, “ipp-operations-security-policy-col”? Gack…) Is there anything like this in the SM?
Smith
On 2014-01-24, at 9:31 AM, Michael Sweet <msweet at apple.com> wrote:
> Smith,
>> On Jan 24, 2014, at 12:24 AM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
>> Greetings,
>>>> I came across a scenario that I think needs characterization in the implementor’s guide. The scenario is this: a Printer has IPPS enabled but conventional IPP disabled, and it receives a “conventional” HTTP connection from a client. How should the printer respond?
>> A HTTP sever can return a 426 status with or without the Expect: 100-continue header in the request. This is already covered in RFC 2817.
>> Clients that do not support TLS Upgrade will simply treat the 426 status as a hard error.
>>> ...
>> I’m also not sure whether this is really a legitimate scenario. If there are some operations that should never require TLS or any form of authentication (the two are related but not the same) then perhaps the Client will not be upgraded right away, and then will not be expecting a later upgrade, and may leak information “accidentally”. For instance, if the Client does a Get-Printer-Attributes operation request that includes the HTTP/1.1 Expect header, it may get back a HTTP 100 Continue. If it switches to a different operation, like Validate-Job or Create-Job, I think it should once again include the HTTP/1.1 Expect header. This specific recommendation detail is currently not covered in wd-ippig20-20140108.pdf section 8.
>> Yes, the Client should always send Expect: 100-continue unless it knows the Printer does not support it (which is buggy behavior anyways, but ...)
>>> Am I off in the weeds? This seems to me like a legitimate concern. If I was a new Client implementor, I’d want to know at what points in the algorithms we cover in section 4 I should be sending an HTTP/1.1 Expect, what points I should be expecting a redirect before sending potentially sensitive information on the wire, etc.
>> It goes beyond TLS - some IPP operations may require authentication, others may not depending on the policy configured in the Printer. So Clients should always include the Expect header unless they know the Printer does not support it, and that allows the correct things to happen without leaking information the Server wants to be confidential based on its configuration.
>> Clients, of course, should probably always support TLS and always include the Upgrade header indicating their willingness to upgrade to TLS, at a minimum. And there should be a preference for IPPS when the Printer supports both IPP and IPPS (or at least a way to select that, given the overhead of TLS...)
>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3319 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140124/84e3b5ac/attachment.p7s>