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

From: "Rizzo, Christopher via ipp" <[email-masked]>
Date: Tue, 15 Jun 2021 18:43:17 +0000

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?

√ ~/OneDrive - Xerox/pwg/ipp/everywhere/sw-ippeveselfcert11-20210517(1629)> ./dnssd-tests.sh boxster
B-1. IPP Browse test: FAIL
B-2. IPP TXT keys test: B-3. IPP Resolve test: FAIL
B-4. IPP TXT values test: B-5. TLS tests: SKIP
B-5.1 HTTP Upgrade test: SKIP
B-5.2 IPPS Browse test: SKIP
B-5.3 IPPS TXT keys test: SKIP
B-5.4 IPPS Resolve test: SKIP
B-5.5 IPPS TXT values test: SKIP
Summary: 10 tests, 0 passed, 4 failed, 6 skipped
Score: 60%
boxster DNS-SD Results.plist: Found non-key inside <dict> at line 17
?1 ~/OneDrive - Xerox/pwg/ipp/everywhere/sw-ippeveselfcert11-20210517(1630)>

===========================

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). 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.

Chris

On 5/17/21, 3:00 PM, "ipp on behalf of Michael Sweet via ipp" <[email-masked] on behalf of [email-masked]> wrote:

    [This last call starts today, May 17, 2021 and ends no earlier than May 31, 2021]

    All,

    I have posted a beta of the IPP Everywhere v1.1 Printer Self-Certification Tools Update 3 to:

    	https://ftp.pwg.org/pub/pwg/ipp/wd/sw-ippeveselfcert11-20210517-macos.zip
    	https://ftp.pwg.org/pub/pwg/ipp/wd/sw-ippeveselfcert11-20210517-rhel.tar.gz
    	https://ftp.pwg.org/pub/pwg/ipp/wd/sw-ippeveselfcert11-20210517-ubuntu.tar.gz
    	https://ftp.pwg.org/pub/pwg/ipp/wd/sw-ippeveselfcert11-20210517-windows.msi

    This update fixes the following issues:

    - The DNS-SD tests now look for a TLS key whose value contains a TLS version
      number (Issue #64)
    - The document tests now wait for each job to complete before proceeding to the
      next job (Issue #66)
    - Finishing options were not reported correctly by `ippevesubmit` in the JSON
      file (Issue #67)
    - The `media-needed` test did not work on streaming printers (Issue #68)

    Please respond to this message once you have tested this update, along with any issues you have encountered.

    ________________________
    Michael Sweet

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet via ipp <[email-masked]>
Date: Tue, 15 Jun 2021 21:04:45 -0400

Chris,

> On Jun 15, 2021, at 2:43 PM, Rizzo, Christopher <[email-masked]> wrote:
> 
> Hello All,
> 

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...)

> ...
> 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