Please look over Keith's reply to each of the concerns that were raised in
the Monterey meeting earlier this week. I would like to have your quick
feedback on Keith's latests suggestions. Does his proposed resolutions
in combination with the offer to get some real expert help (which we
have been loooking for for a long time), change your attitude towards
the IPP scheme proposal? Keith would like to get our reaction by
July 15th. I will be on the road on July 13 and 14 and will
probably only be able to check mail early and late in the day.
Carl-Uno
> -------------------------------------------------------------------
> Summary Conclusions
> -------------------------------------------------------------------
>
> The IPP working group has serious concerns regarding integrating a new
> "ipp:" URL into our specifications. The following issues have been
> raised with regards to usage of the "ipp:" scheme.
>
> 1. There is currently no defined way for a single "ipp:" URL to
> indicate whether or not a particular IPP server offers "secure"
> connections. Throughout the IPP model document, numerous
> assumptions are made with regards to our usage of the "http:" URL
> to reference IPP objects, chief among these assumptions is that
> IPP clients treat URL syntax beyond the "host" part of an HTTP URL
> as opaque.
>
> The IPP working group feels that any specification for security
> parameters within URL syntax should be a "standard" solution and not
> specifically a "one-off" or one-time only solution for IPP.
> The effort required to put together a group or effort to accomplish
> this is out-of-scope for our current charter.
I agree that there is a need to be able to specify the security
technology which is to be used, especially because there is currently
no effective way for client and server to negotiate security technology.
The emerging consensus for indicating authentication technology in a
URL is to use an AUTH= parameter. However, as far as I can tell,
this parameter has not been extended to specify uses of TLS.
However, a separate URL type such as "https" is also insufficient for
IPP's purposes. SSL was designed to authenticate servers to clients,
not the other way around, and this heritage still shows in TLS.
The TLS protocol does not have any way for a server to inform a
client about which certificate authorities it trusts. Unless all
IPP servers are going to trust the same certificate authority
(highly unlikely), an IPP client that talks to different servers will
need multiple key certificates (up to one for each IPP server it
wants to talk to), and therefore the client either needs to know which
certificate to send to each server, or it needs to know which CAs
the server supports.
If some sort of prior, out-of-band, authorization is used to establish
an association between an IPP client and an IPP server, this step
will need to return credentials (perhaps an X.509 certificate, perhaps
a password for use with digest authentication) that the client can
use when authenticating itself to that server. In this case, no extra
parameters are needed for the printer URL - rather, the client will
internally maintain lists of authentication credentials indexed by the
printer name or URL. The authentication method to be used can be
considered part of those credentials.
If it's desired to make IPP work without prior authorization
(and assuming the server requires authentication at all), the
client is still going to need to know what authentication method to
use and which CAs the server supports. This is more information than
can be conveyed in one bit (the difference between using "http"
and "https").
> 2. There is no straightforward way to configure HTTP client proxy
> capability for "proxying" IPP. Currently, there are specific proxy
> configuration options for HTTP clients, such as FTP, GOPHER, HTTP,
> WAIS, etc. There is no option for proxying "ipp:" URLs and this
> deficiency could lead to confusion for the end user. Also, to correctly
> configure a proxy service for IPP, the user will have to "know"
> that IPP actually uses HTTP, and that for IPP proxy service the user
> must configure an HTTP proxy.
I don't understand why this is a problem, because existing web clients
can't usefully talk to IPP servers anyway. They can't generate
application/ipp requests nor can they parse application/ipp responses.
So naturally they don't have configuration options to talk to IPP proxies
either.
As for the potential for end-user confusion: there's far greater
potential for end user confusion if printers are named with http: URLs.
I don't think the configuration management issues for proxies are
that difficult to deal with. The IPP configuration can simply have
a box like:
------------------------------------------------------
[ ] make direct connections to an IPP server
[x] tunnel outgong IPP requests through an HTTP proxy.
proxy host name: [foo.bar.com]
proxy port number: [8080]
------------------------------------------------------
This isn't any worse than for any other protocol.
These are nothing in comparison to the configuration management issues
for security. How is an IPP client is going to be able to authenticate
itself to arbitrary IPP servers around the world? If it uses TLS,
it's potentially going to need to have a variety of key certificates
on hand (each signed by a different CA), and know which CAs and
certificate types are recognized by each server, so that it knows
which certificates to send to which servers.
> 3. Similar to the end-user configuration problem in #2 above, there is
> currently no proxy configuration option for IPP proxy in existing
> proxy server software. IPP will be a "special case" wherein the
> administrator will have to know the special relationship between
> IPP URLs and HTTP URLs.
I don't see why this is a problem with the IPP proposal. The IPP
proposal is to use an http: URL with an explicit port number, so
that it will be compatible with http proxies.
> 4. Future use of the "ipp" scheme is compromised by using the new "ipp"
> scheme in the translated form implied by the proposed "ipp:" scheme.
> The IPP working group would like to reserve use of the "ipp" scheme
> for a pure IPP client/server protocol implementation in the future
> (one that does not require utilization of an existing HTTP
> infrastructure). In this environment, it seems appropriate to attach
> the "ipp" URL to this future protocol, rather than the initial IPP
> protocol that is just carried in a MIME type within HTTP.
>
> For example, in a future implementation of an IPP scheme that does
> not utilize HTTP, existing IPP clients would still attempt to
> translate the "ipp:" scheme into an "http:" scheme, and would do so
> incorrectly, since the future "ipp:" scheme protocol might not use
> HTTP as a transport.
Anytime a new URI scheme name is defined, it is "compromised" against
some future use of the scheme name with a different protocol. That's
not a real problem; we could always define "ipp2" or some other name
for the new protocol. Chances are we'd want to do that anyway;
if there were two versions of IPP it would be confusing to use "http"
to talk to IPP version 1 and "ipp" to talk to IPP version 2 servers.
If what you're saying is that HTTP was a Bad Idea and you want to
do something different in the future, that implies that this protocol
is not yet suitable for standardization. If a future version of IPP
would not make use of the "HTTP infrastructure", then there is no
reason *not* to use "ipp:" for the current protocol -- since the only
problems with the use of "ipp:" are the lack of support in the
HTTP infrastructure. Might as well cross this bridge now.
My opinion is that HTTP is a sub-optimal but sufficient transport
for IPP, and that it is better to settle on the current version of
IPP and make it work with the ipp: URL now, than to try to do it later.
By the time there is a completely new printing protocol, it is likely that
there will be a standard URI resolution mechanism - which would allow
a client to look up an ipp: URL and find out which printing protocols
the server supports, before opening up a connection to the server.
This would allow a smooth transition from IPP 1.0 to the new protocol,
while using the same URLs.
> 5. The proposal introduces "compound" spoofing by using an "ipp:" scheme
> and transparently translating it to an "http:" scheme An initial
> concern was the fact that there was no way to tell that IPP was
> actually being used by looking at an HTTP URL. However, publishing
> and using only IPP URLs to the user and administrator community might
> hide the fact that IPP is actually using HTTP.
This is not a problem. IPP's use of HTTP is an implementation artifact,
not something that users need to be concerned with. Yes, users might
end up needing to know that they can tunnel IPP over an HTTP proxy.
But this is easily communicated through user interfaces such as that
above. And if this technique is approved, it is likely to be regarded
as a convenience.
(Some folks on the IAB and IESG are still not convinced that IPP should
be able to tunnel over existing proxies; the counter argument is that
IPP is going to need proxies anyway, so you might as well use one that
already exists.)
It's a bit misleading to call this "compound" spoofing, since there
is only one layer of "spoofing" going on.
> 6. Compound schemes is a new idea and not well understood in its'
> ramifications. In the current IANA registry for URL schemes, there
> are no examples that indicate that scheme "translation" to another
> scheme is required.
IPP is the first group to try to layer something on top of HTTP.
So naturally there are no examples for how to do this. That's
what comes with breaking new ground.
Note that the translation is only required to talk to HTTP proxies.
The general case is that the IPP client talks directly to the IPP
server, and there's no URI translation going on at all.
> 7. All applications that include URI/URL recognition features will have
> to be updated to include support for the new "ipp:" URL.
The applications have to be updated anyway. There are lots of new URI
types being defined; any generic URI parsing application that can only
handle specific URL types is already broken. And any application that
is actually going to make use of ipp: URLs (as opposed to just parsing
them), is going to have to be updated to generate application/ipp
requests, parse application/ipp results, and otherwise provide a useful
user interface to printers.
> 8. Existing network infrastructure tools and utilities would need to
> be modified in order to understand the "special" relationship
> between IPP and HTTP URLs.
>
> The working group considers IPP printing an "HTTP application", and
> therefore the usage of an "ipp:" URL scheme must maintain a special
> relationship with "http:" URLs. The definition of such a "compound"
> URL scheme, wherein an "ipp:" scheme is layered or translated to an
> "http:" scheme, is somewhat unusual, and the impact of such a definition
> on the protocol design and deployment is not generally well understood.
The IESG considers IPP separate and distinct from normal web service,
requiring a separate URI type. The layering of IPP on top of HTTP,
while somewhat unusual, does not change this.
> This analysis document has identified a partial list of issues regarding
> the integration of the new "ipp:" scheme. It is anticipated that other
> unforeseen issues exist, since this technique has not been prototyped.
>
> If the usage model described herein were adopted, these issues raised in
> this analysis pose a significant negative impact on the implementation
> and deployment of current IPP specifications, as well as potential
> interoperability with future revisions of the protocol.
This negative impact has to be weighed against the considerable negative
impact associated with use of the http: scheme.
Summary of my position:
1. I agree that more work needs to be done to specify security level
in IPP URLs. The "https" scheme (which wouldn't be accepted anyway)
is insufficient, and use of the AUTH= parameter with TLS is not
sufficiently well defined for any other URL scheme, to allow IPP
to cut-and-paste another specification.
Note that these are as much limitations of HTTP and TLS (to fail to
provide adequate negotiation of security parameters) as of URLs.
If there were a better way for client and server to negotiate security,
this would lessen the need to expose this information in the URL.
Note that this is much a limitation of HTTP and TLS (to fail to
provide adequate negotiation) as of URLs.
2. I believe the "negative impact" claimed by the IPP group is
exaggerated, and does not consider the negative impact to the
community of overloading the http: URI scheme.
I respect the IPP group's concern that translation of IPP URLs
while tunneling over HTTP proxies is untried and may cause operational
problems. However, the IPP group is ignoring IESG concerns about
operational problems that might be caused by reusing HTTP proxies
in the first place to circumvent firewall policy, or the confusion
resulting from users' inability to distinguish printer URLs from
http: URLs.
If IPP's use of HTTP proxies causes too many problems, it may be
necessary to reconsider using HTTP proxies - or to allow people
to use them, but warn that this might not always work. Sooner
or later the proxies will support IPP. Of course it's nice if
proxies support a new protocol immediately, but if they don't -
this is no more of a barrier than any other new protocol has to face.
My proposal:
The IPP documents will not be approved as a Proposed Standard until
they are fixed to use ipp: URLs instead of http: URLs.
With an eye toward making them acceptable to IESG while addressing
the IPP group's concerns:
- I will recruit a team of experts from the HTTP working group
and ask them to quickly review the ipp: scheme proposal for potential
interoperability problems with proxies.
- I will recruit experts from the web and TLS communities to design
appropriate URL parameters for use with TLS, which can be shared
by other URL schemes besides ipp:.
The IPP documents have been submitted for IESG ballot, and may be
on IESG's agenda for discussion as early as July 16th. I would
therefore like a decision from IPP by July 15th as to whether
the IPP working group is willing to pursue this course of action.
Note that there may still be other IESG concerns with this protocol,
particularly on security. We won't know about those until the IESG
finishes its ballot.
Keith