Subject: [apps-discuss] Request for Apps Area review of IPP over HTTPs and 'ipps' URI Scheme (19 September 2013)

From: Ira McDonald <[email-masked]>
Date: Thu, 19 Sep 2013 12:45:56 -0400

Hello,

The IEEE-ISTO PWG Internet Printing Protocol WG would like to request
IETF Apps Area review of our IPP over HTTPS Transport Binding and
'ipps' URI Scheme:

http://www.ietf.org/internet-drafts/draft-mcdonald-ipps-uri-scheme-08.txt

Please note that this document has been already been reviewed on the
IETF URI Review mailing list (and revised accordingly).

This document does NOT specify a new protocol, but merely a transport
binding for IETF IPP/1.1 (RFC 2910/1911) that requires that TLS always
be started *before* sending any HTTP application layer requests - as
opposed to using the rarely implemented HTTP Upgrade (RFC 2817),
a source of security problems in shipping IPP printers (essentially all
network printers for the last decade).

Cheers,
- Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this document)

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
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

---

From: t.petch <[email-masked]>
Date: Thu, 26 Sep 2013 12:11:46 +0100

Ira

The aspect that strikes me most is not so much an apps one as a security
one, that current I-Ds using TLS tend to say more about what forms of
security are acceptable.  For example, there has been much recently
about the checks to perform on a certificate and often there are
comments about the acceptable cipher suites.  Also, all the references
are to TLS 1.2 which, last I saw, is not widely supported - again, I
would expect some comment thereon.  I expect that the applicability of
this is not the usual 'across the public Internet' one which may colour
what is acceptable.

Otherwise, I find the style slightly unfamiliar.

The abbreviations come at the end whereas they are commonly at the
beginning.

There is a non-normative section 3 in the middle of normative ones -
commonly, that is an appendix.

The definitions in section 2 I would find easier without the repeated
 In this document,
which I think redundant.

You include query in the scheme syntax but it is never reference or
appears in any example.

Has this I-D any relationship to RFC3510?

Tom Petch

----- Original Message -----
From: "Ira McDonald" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; "Ira McDonald"
<[email-masked]>; "Michael R Sweet" <[email-masked]>
Sent: Thursday, September 19, 2013 5:45 PM

> IETF Apps Area review of our IPP over HTTPS Transport Binding and
http://www.ietf.org/internet-drafts/draft-mcdonald-ipps-uri-scheme-08.tx
t
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

------------------------------------------------------------------------
--------

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Ira McDonald <[email-masked]>
Date: Thu, 26 Sep 2013 11:48:25 -0400

Hi Tom,

Thanks for you comments and questions.  My replies are inline below.

Cheers,
- Ira

> this is not the usual 'across the public Internet' one which may colour

We brought this document to the IETF Apps Area because all original
IETF IPP standards were developed there, including RFC 3510.

The intended usage is primarily 'across the public Internet', in support of
IEEE-ISTO PWG IPP Everywhere (PWG 5100.14) which support high-function
printing from mobile devices (cellphones, tablets, laptops).  Mobile phones
and major operating systems are now implementing this standard.

  ftp://ftp.pwg.org/pub/pwg/candidates/cs-ippeve10-20130128-5100.14.pdf

In the near future, this intended usage will be much more important with the
new IPP Shared Infrastructure Extensions (new IPP cloud print operations).

  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20130923-rev.pdf

TLS 1.2 is commonly supported by printers and multifunction devices, due
due to use of IPP/2.0 w/ TLS 1.2 in the Apple AirPrint technology in 2010.

We didn't want to place mandatory conformance requirements on TLS 1.2
usage, beyond those specified in RFC 5246 itself.  Since quite a few cipher
suites are now defined for use w/ TLS 1.2, this seems problematic.  Your
advice and guidance would be much appreciated.

We could consider allowing alternate use of TLS 1.1, if that's appropriate,
although IPP Everywhere certified printers will begin shipping in October,
so we'll have to be a bit careful in making changes.

> The abbreviations come at the end whereas they are commonly at the

I'm confused - do you mean "ABC (Another Big Cloud)" or the location of
the Abbreviations section in an appendix?  We put this section in an
appendix based on advice on the IETF URI review mailing list, although
the IEEE-ISTO PWG document template now puts it into section 2 with
other terminology - would that be more appropriate?

> commonly, that is an appendix.

Should we move the informative section 3.1 to an appendix?  It was placed
in section 3 to introduce the behavior differences between 'ipp' and 'ipps'
URI schemes.

> The definitions in section 2 I would find easier without the repeated

Thanks - we'll remove the redundant phrases.

> You include query in the scheme syntax but it is never reference or

We included it because it was present in RFC 3510 and RFC 3986. It is
*never* used in the IPP protocol (on port 631), because filtering is done
in-band in the IPP Get-Printer-Attributes and Get-Job-Attributes
operations.

Should we just remove the query syntax?   This could cause breakage
with some existing IPP print spoolers, since it was present in RFC 3510.

> Has this I-D any relationship to RFC3510?

Yes - it complements RFC 3510, as stated in Appendix A and elsewhere.

The 'ipps' URI scheme was developed first in CUPS (standard print spooler
on Mac OS X and all UNIX and Linux distributions) because printers were
in fact not supporting HTTP TLS Upgrade (RFC 2817) or else were doing it
wrong (e.g., partway through an IPP session - defeating strong
authentication
of client identity).

For mobile print over the public Internet, failure to negotiate a TLS secure
transport with data encryption is not acceptable.

Should we add discussion of the relationship to RFC 3510 to Introduction?

---

From: Claudio Allocchio <[email-masked]>
Date: Thu, 26 Sep 2013 18:10:20 +0200 (CEST)

Hi Ira,

We also have the reviews from APPSDIR avalable now.

BTW, when do you need the review to be done?

best!
Claudio

>>> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: Ira McDonald <[email-masked]>
Date: Thu, 26 Sep 2013 12:22:41 -0400

Hi Claudio,

I think we'd like the review to be done ASAP - IPP Everywhere printers will
start
shipping October and major operating system support (on the client side)
will
also come quite soon.

Cheers,
- Ira

On Thu, Sep 26, 2013 at 12:10 PM, Claudio Allocchio <
[email-masked]> wrote:

>> http://sites.google.com/site/**blueroofmusic<http://sites.google.com/site/blueroofmusic>
>> http://sites.google.com/site/**highnorthinc<http://sites.google.com/site/highnorthinc>
>>  ftp://ftp.pwg.org/pub/pwg/**candidates/cs-ippeve10-**
>> 20130128-5100.14.pdf<ftp://ftp.pwg.org/pub/pwg/candidates/cs-ippeve10-20130128-5100.14.pdf>
>>
>>  ftp://ftp.pwg.org/pub/pwg/ipp/**wd/wd-ippsix10-20130923-rev.**pdf<ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20130923-rev.pdf>
>>
>>>>  http://www.ietf.org/internet-**drafts/draft-mcdonald-ipps-**
>>> uri-scheme-08.tx<http://www.ietf.org/internet-drafts/draft-mcdonald-ipps-uri-scheme-08.tx>
>>> t
>>>
>>>>
>>>> a source of security problems in shipping IPP printers (essentially
>>>>
>>> all
>>>
>>>> - Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this
>>>>
>>> document)
>>>
>>>>
>>>>
>>>> http://sites.google.com/site/**blueroofmusic<http://sites.google.com/site/blueroofmusic>
>>>> http://sites.google.com/site/**highnorthinc<http://sites.google.com/site/highnorthinc>
>>> ------------------------------**------------------------------**
>>> ------------
>>> --------
>>>
>>>
>>>  ______________________________**_________________
>>>> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>>>>
>>>>
>>>
>>>
>>>
>>
> ------------------------------**------------------------------**
> ------------------
>            PGP Key: http://www.cert.garr.it/PGP/**keys.php3#ca<http://www.cert.garr.it/PGP/keys.php3#ca>
>

---

From: t.petch <[email-masked]>
Date: Thu, 26 Sep 2013 18:29:41 +0100

----- Original Message -----
From: "Ira McDonald" <[email-masked]>
To: "t.petch" <[email-masked]>; "Ira McDonald"
<[email-masked]>
Cc: <[email-masked]>; "Michael R Sweet" <[email-masked]>
Sent: Thursday, September 26, 2013 4:48 PM

Ira

TLS 1.2 is quite rare but has few flaws, TLS 1.0 is common but flawed,
so if you can get support for 1.2, then that is the right choice.

You do not have interoperability without a common ciphersuite so I am
used to 'XXX over TLS' specifying one, even if it is the default from
RFC5246 - TLS_RSA_WITH_AES_128_CBC_SHA - (which is, perhaps, not as
secure as it might be, e.g. not for a protocol which will be around for
a long time in exposed places and, I imagine, will see a lot of attacks,
not something I realised on first reading.  I am not competent to assess
the threats and recommend a better one but I do see the discussions
thereof on the TLS list.  I would like to see a Security Directorate
review sooner rather than later.  In general, I see much more focus on
this aspect of protocols than a few years ago and so was expecting a
stronger Security Considerations).

> other terminology - would that be more appropriate?

I am used to RFC putting it in section 2 (and I am used to URI reviews
on the [email-masked] list, where I would have commented earlier:-).

> in section 3 to introduce the behavior differences between 'ipp' and
'ipps'

You clearly label it as Informative so ....  Is your intended audience
one that is already familiar with ipp scheme?  If so, I would move it,
if not, leave it alone.

> with some existing IPP print spoolers, since it was present in RFC
3510.

No, but add a comment on its nonuse as you have here.

> Should we add discussion of the relationship to RFC 3510 to
Introduction?

Good idea but I was thinking more does this update RFC3510 in any way,
or just sit alongside it as an alternative?

Tom Petch

> ><snip>

---

From: Ira McDonald <[email-masked]>
Date: Thu, 26 Sep 2013 17:00:48 -0400

Hi Tom,

Thanks your quick and helpful replies.

Review by the Security Directorate would certainly be a good idea.

We can *recommend* other cipher suites, in addition to the requirements
in RFC 5246, but we can't *mandate* those, because a LOT of printers
have shipped w/ 'ipps' support for several years now.

We'll make your other suggested changes in the next draft.

The IPP over HTTPS Transport Binding and 'ipps' URI Scheme (which
mandates starting TLS before sending any HTTP requests) is just an
alternative to 'ipp' URI Scheme (RFC 3510).  This spec does not
update RFC 3510.  In general 'ipp' URI should only be used inside
an enterprise network - they are not safe in the public Internet.

I think it's better to move the review of the order of protocol setups
in RFC 3510 back to an appendix.  Only operating system vendors
and printer vendors will ever read this RFC (probably), because the
hoped for uptake of IPP/1.1 by browser vendors never happened.

Cheers,
- Ira