Re: IPP WG Last Call: IPP Everywhere v1.1 Printer Self-Certification Tools Update 3

Michael Sweet via ipp <[email protected]> Tue, 15 Jun 2021 21:04:45 -0400
Newsgroups	gmane.ietf.ipp
Message-ID	<[email protected]>
Chris,

> On Jun 15, 2021, at 2:43 PM, Rizzo, Christopher <[email protected]> wrote:
> 
> Hello All,
> 
> I know I've been out of the loop for a while, trying to get back into the swing of things but having trouble keeping up with the work.
> 
> Anyway, I am testing the latest IPP Everywhere self cert tests and uncovered a couple of issues?
> 
> 1.  If a device can be configured to not support IPP, but only support IPPS, then all dnssd-tests.sh fail, because "ippfind _ipp._tcp,_print" fails to discover the printer as the printer is not advertising _ipp._tcp (note in the response below there is an HP device supporting both IPP and IPPS, but the device boxster is configured to only support IPPS):
> 
> ?130 ~/OneDrive - Xerox/pwg/ipp/everywhere/sw-ippeveselfcert11-20210517(1627)> ./ippfind _ipp._tcp -T 5
> ipp://HP5CB901EB7BE8.local:631/ipp/print
> √ ~/OneDrive - Xerox/pwg/ipp/everywhere/sw-ippeveselfcert11-20210517(1628)> ./ippfind _ipps._tcp -T 5
> ipps://HP5CB901EB7BE8.local:443/ipp/print
> ipps://boxster.local:443/ipp/print
> √ ~/OneDrive - Xerox/pwg/ipp/everywhere/sw-ippeveselfcert11-20210517(1629)>
> 
> Should the IPP Everywhere tests work for those devices that only support IPPS?

No, for certification your printer is expected to support unencrypted IPP - it is a base requirement and something that will ensure your printer works with as many clients as possible out-of-the-box...

(We can talk about allowing printers to only support IPPS in IPP Everywhere v2.0, but for v1.1 the requirement is IPP and IPPS is only recommended...)

> ...
> 2. The other issue I have is associated with RFC 2817 HTTP Upgrade to TLS.  I run this test with boxster re-configured to support both IPP and IPPS. In this test Wireshark trace shows RFC 2817 Section 3.2 Mandatory Upgrade request coming from dnssd-test (ipptool):
> 
> Packet 65 in attached Wireshark trace
> OPTIONS * HTTP/1.1
> Connection: Upgrade
> Upgrade: TLS/1.2,TLS/1.1,TLS/1.0
> 
> boxster responds with 101 Switching Protocols:
> 
> Packet 68 in attached Wireshark trace
> HTTP/1.1 101 Switching Protocols
> Upgrade: TLS/1.2, HTTP/1.1
> Connection: Upgrade
> 
> But the communication then ends. Per RFC 2817 Section 3.3 reference is made to RFC 2616 section 10.1.2 "The server will switch protocols to those defined by the response's Upgrade header field immediately after the empty line which terminates the 101 response".  However, since I've never seen this in a trace, I do not know what the server is supposed to respond with (what those packets look like).

You should see a TLS handshake.

> If there is a TLS upgrade handshake that needs to occur, doesn't the client have to initiate it with a TLS "Client Hello"? Does anyone have a Wireshark trace that shows a working functionality for this and if so can you provide it? boxster is running an Apache HTTP server configured to support RFC 2817, but it appears it is Apache itself which is not properly supporting the RFC 2817 upgrade, as it appears to not properly implement RFC 2616 section 10.1.2 in this instance.

AFAIK, Apache does not support HTTP Upgrade to TLS... :/  And there are a number of Apache implementation choices that make it really hard to implement a conforming IPP service on top of it...

________________________
Michael Sweet

_______________________________________________
ipp mailing list
[email protected]
https://www.pwg.org/mailman/listinfo/ipp
signature.asc (application/pgp-signature, 874 B)