Subject: [IPP] A few points of feedback on "IPP over HTTPS and ’ipps’ URI Scheme" draft 9

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Fri, 28 Feb 2014 05:33:33 +0000

Greetings,

Some folks in HP were reading over the “IPP over HTTPS and ’ipps’ URI Scheme” document, and they had some questions about port numbers, which triggered my re-reading it.  I wish to report the following issues:

Section 3 item (2), Page 7:

    2) The IPP Client converts the ’ipps’ URI to an ’https’ URI
       (replacing ’ipps’ with ’https’ and inserting port 631);

This overlooks the possibility that there may be an alternate port in the URI, as described more completely in section 4.2.  To accommodate this, I think it is more appropriate for this clause to be phrased more along these lines:

    2) The IPP Client converts the ’ipps’ URI to an ’https’ URI
       (replacing ’ipps’ with ’https’ and inserting the port number
       from the URI or port 631 if the URI doesn’t include a port
       number);

Section 4.2, Page 9:

    Note:  IPP Printers ought to be cautious about depending on URI
           lengths above 255 bytes, because some older IPP Client
           implementations might not properly support these lengths.

Should “ought” really rather be “SHOULD”?

Section 4.2, Page 9: This should include a reference to section 4.3:

    If the port is empty or not given, then port 631 MUST be used.

Section 4.3, Page 10: This should include a reference to section 4.3:

    An ’ipps’ URI is transformed into an ’https’ URI by replacing "ipps:"
    with "https:" and inserting port 631 (if the ’port’ is not present in
    the original ’ipps’ URI).

Section 4.3, Page 10: Missing mention of RFC 6335 or similar references, that provide an explanation why the existing well-known port number (631) is being overloaded for the TLS variant may be appropriate.  This should be included for the sake of those that aren’t familiar with this newer “port number allocation design pattern” being used by IANA and the IETF.

Section 4.6.1, Page 11: “The first and second ’ipps’ URI above MUST be resolved to port 631 (IANA assigned well-known port for IPP).” should refer to section 4.3.

Section 4.7, Page 12: This should include a reference to section 4.3:

    - A port that is empty or not given MUST be treated as equivalent to
      the well-known port for that ’ipps’ URI (port 631).

Section 5.1, Page 13: Grammatical error:

    d) MUST the required TLS version(s) according to the corresponding
       IPP versions as defined in section 7 of this specification;

Section 5.1, Page 13: Include a reference to section 4.3:
 
    e) MUST only send IPP protocol connections to IANA assigned
       well-known port 631 or to the explicit port specified in a given
       ’ipps’ URI;

Section 5.2, Page 14: Grammatical error
 
    d) MUST the required TLS version(s) according to the corresponding
       IPP versions as defined in section 7 of this specification;

Section 5.2, Page 14: This clause should also include either a reference to and/or a statement that port 631 is to be used for both conventional IPP over HTTP as well as IPP over HTTPS.

    e) MUST only listen for incoming IPP protocol connections on
       IANA-assigned well-known port 631 and MUST NOT listen for incoming
       IPP protocol connections on any other port, unless explicitly
       configured by system administrators or site policies;

Section 7.2.4, Page 18: Grammatical error - extra instance of “or”

    Either service discovery or directory protocols SHOULD be used first
    or or an IPP Client SHOULD first

Section 9: Add reference to RFC 6335 or similar references, that provide an explanation why the existing well-known port number (631) is being overloaded for the TLS variant may be appropriate.  This should be included for the sake of those that aren’t familiar with this newer “port number allocation design pattern” being used by IANA and the IETF.  There is a reference to [PORTREG] in section 9.2 but this seems inadequate to me.

I’ve marked up copy of the PDF draft, that I will send to Ira separately so I don’t spam everyone else.  I don’t know if this feedback is “too late” but I thought I’d send it on anyway.

Cheers,

Smith

/**
    Smith Kennedy
    Hewlett-Packard Co.
*/

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

---

From: Ira McDonald <[email-masked]>
Date: Fri, 28 Feb 2014 11:19:44 -0500

Hi Smith and HP folks,

These excellent comments are all very timely!

I'll issue a new draft soon that incorporates all of these improvements.  We
hope to convince the IETF Applications Area Directors to put that version
into IETF Apps Last Call and assign a Document Shepherd to then take it
to IETF Last Call.

Related to approaches for using a single port for both a plain application
protocol (over TCP) and equivalent secure version (over TLS over TCP):

(1) The IESG (steering group that oversees the IETF) decided against any
more dual-port registrations for application protocols over ten years ago
(we were told we couldn't do it with IPP 1.1, RFC 2911).

(2) I think there's an IAB (parent of IESG) policy somewhere (maybe an RFC)
about port registration.

(3) Note that the "System" range of port numbers (up to 1023), intended
for OS kernel support and assigned by IESG to standards-track RFCs, has
long since been exhausted.

(4) In a standards-track RFC for "ipps:" we aren't allowed to put an annex
with code fragments - but such guidance could be published by the PWG.

(5) Since port 631 has been in use for years for secure IPP ("ipps:") in
CUPS
and supported by multiple printer vendors, we can't change the port number
now (and the IESG would block the publication of "ipps:" entirely if we
tried
to do so).

BTW - here's the link to the current IANA port and service names registry:

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol 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: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Fri, Feb 28, 2014 at 12:33 AM, Kennedy, Smith (Wireless Architect) <
[email-masked]> wrote:

> Greetings,
>
> Some folks in HP were reading over the "IPP over HTTPS and 'ipps' URI
> Scheme" document, and they had some questions about port numbers, which
> triggered my re-reading it.  I wish to report the following issues:
>
>
>     2) The IPP Client converts the 'ipps' URI to an 'https' URI
>        (replacing 'ipps' with 'https' and inserting port 631);
>
> This overlooks the possibility that there may be an alternate port in the
> URI, as described more completely in section 4.2.  To accommodate this, I
> think it is more appropriate for this clause to be phrased more along these
> lines:
>
>     2) The IPP Client converts the 'ipps' URI to an 'https' URI
>        (replacing 'ipps' with 'https' and inserting the port number
>        from the URI or port 631 if the URI doesn't include a port
>        number);
>
>
> Section 4.2, Page 9:
>
> Should "ought" really rather be "SHOULD"?
>
>
>     An 'ipps' URI is transformed into an 'https' URI by replacing "ipps:"
>     with "https:" and inserting port 631 (if the 'port' is not present in
>     the original 'ipps' URI).
>
>
>
> Section 4.3, Page 10: Missing mention of RFC 6335 or similar references,
> that provide an explanation why the existing well-known port number (631)
> is being overloaded for the TLS variant may be appropriate.  This should be
> included for the sake of those that aren't familiar with this newer "port
> number allocation design pattern" being used by IANA and the IETF.
>
>
> Section 4.6.1, Page 11: "The first and second 'ipps' URI above MUST be
> resolved to port 631 (IANA assigned well-known port for IPP)." should refer
> to section 4.3.
>
>
>       the well-known port for that 'ipps' URI (port 631).
>
>
>        'ipps' URI;
> Section 5.2, Page 14: This clause should also include either a reference
> to and/or a statement that port 631 is to be used for both conventional IPP
> over HTTP as well as IPP over HTTPS.
>
> Section 7.2.4, Page 18: Grammatical error - extra instance of "or"
>
> Section 9: Add reference to RFC 6335 or similar references, that provide
> an explanation why the existing well-known port number (631) is being
> overloaded for the TLS variant may be appropriate.  This should be included
> for the sake of those that aren't familiar with this newer "port number
> allocation design pattern" being used by IANA and the IETF.  There is a
> reference to [PORTREG] in section 9.2 but this seems inadequate to me.
>
> I've marked up copy of the PDF draft, that I will send to Ira separately
> so I don't spam everyone else.  I don't know if this feedback is "too late"
> but I thought I'd send it on anyway.
>
> Cheers,
>
> Smith
>
> /**
>     Smith Kennedy
>     Hewlett-Packard Co.
> */
>
>
>
>

---

From: Michael Sweet <[email-masked]>
Date: Fri, 28 Feb 2014 11:39:51 -0500

Smith,

Some comments inline below...

On Feb 28, 2014, at 12:33 AM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> ...

IPP's URI type is pretty clearly defined with a maximum size of 1023 octets.  I believe this came from the original "ipp" URI scheme (RFC 3510), so perhaps we can just remove this line since I am not aware of any IPP clients that support "ipps" with this limitation...

> ...

This is good and appropriate IETF LC feedback, thank you!

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Michael Sweet <[email-masked]>
Date: Fri, 28 Feb 2014 11:47:34 -0500

Ira,

> with code fragments - but such guidance could be published by the PWG.

I think we could get away with a short mention of CUPS with an informative reference to the CUPS web site (https://www.cups.org/); include it in the security considerations - since IPP and IPPS use the same port, the IPP Server/Printer needs to determine whether the initial request data is a TLS ClientHello or a HTTP request, strategies for doing so, and a pointer to an existing implementation (CUPS).

(FWIW, all CUPS does is check whether the initial bytes look like a DELETE, GET, HEAD, OPTIONS, POST, PUT, or TRACE request.  If not, we let the TLS library validate the ClientHello)

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Fri, 28 Feb 2014 18:31:02 +0000

Thanks Ira!  

I did look at the IANA port registry page, at the top of which there are many references to RFC 6335.  Unfortunately RFC 6335 doesn’t contain statements or references to documents that state the IESG’s position on this.  

One could imagine an informative RFC that updates RFC 6335 and also includes a code example demonstrating how to support TLS and non-TLS variants using POSIX sockets and openssl or similar free software APIs.

Smith

On 2014-02-28, at 9:19 AM, Ira McDonald <[email-masked]> wrote:

> (5) Since port 631 has been in use for years for secure IPP ("ipps:") in CUPS
> now (and the IESG would block the publication of "ipps:" entirely if we tried
> to do so).
> 
> On Fri, Feb 28, 2014 at 12:33 AM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> Greetings,
>

---

From: Ira McDonald <[email-masked]>
Date: Fri, 28 Feb 2014 17:27:19 -0500

Hi Smith,

I just found this interesting higher level summary of the functions and
methodology
of IANA written by Jari Arkko, Chair of the IETF:

  http://www.ietf.org/blog/2014/01/iana/

I'm still searching for an I-D or an ICANN/IANA policy that discusses
dual-use ports
(for UDP/DTLS or TCP/TLS) and IETF recommendations for supporting them.

Cheers,
- Ira

On Fri, Feb 28, 2014 at 1:31 PM, Kennedy, Smith (Wireless Architect) <
[email-masked]> wrote:

> Thanks Ira!
>
> I did look at the IANA port registry page, at the top of which there are
> many references to RFC 6335.  Unfortunately RFC 6335 doesn't contain
> statements or references to documents that state the IESG's position on
> this.
>
> One could imagine an informative RFC that updates RFC 6335 and also
> includes a code example demonstrating how to support TLS and non-TLS
> variants using POSIX sockets and openssl or similar free software APIs.
>
> Smith
>
>
>