Subject: IPP> Re: URI scheme and port numbers for TLS

From: Keith Moore <[email-masked]>
Date: Wed, 07 Jan 1998 17:34:02 -0500

> Is it assumed that each application that uses TLS uses its own original
> scheme e.g. "http" or should it allocate a new scheme if combined with TLS
> (Annex E seems to suggest that you use "https" as for SSL3)?

Ideally, a single URL scheme could be used either with or without TLS,
with the authentication and privacy technology to be used negotiated
by the client and server.  Client and server should each be
configurable as to which ciphersuites, CAs, etc. are acceptable to
each party.

In general, neither the scheme name, nor the port number, is
sufficient for such configuration.  For instance, "https" (and port
443) can be used with many different ciphersuites, covering a wide
variety of services and strengths, some of which are unlikely to be
acceptable.  While we don't intend to deprecate https/http and the
other dual-port schemes that are widely deployed, neither do we want
to propagate this mechanism to new protocols.

> Do you see any reasons to allocate new schemes and/or port numbers for IPP
> (differently from HTTP) when using HTTP as transport? If you think new
> schemes and ports are needed, do we need one for use of IPP without TLS,
> and another set for use with TLS?

IANA has been requested to not assign any new "SSL" or "TLS" ports.
For new protocols, TLS must either to be explicitly configured
separately from the port number, negotiated in-band (using STARTTLS or
some such), or assumed by default.

As for IPP:

+ IPP servers listening on port 443 should assume TLS/SSL will
  be used when the connection is opened.
  IPP clients should use "https:", without overriding the port #,
  to indicate they want to talk to an IPP server on port 443.

+ IPP servers listening on other ports, including any port that might 
  be designated specifically for IPP, should assume that neither TLS
  nor SSL is used when the connection is established.  TLS or other
  security technologies might eventually be used on such servers, 
  if someone defines a means of negotiating security in-band over
  HTTP.

  IPP clients should specify "http:", perhaps with a port #
  (other than 443), to indicate that they want to talk to such servers.
  
+ If a specific port is to be allocated for IPP, there should be
  an "ipp:" URL scheme defined, which defaults to that port.

  The definition of the ipp: scheme should also define how security 
  is to be negotiated on that port - whether it defaults to TLS 
  (perhaps with the possibility of fallback to a null encryption 
  layer) or whether it uses in-band negotiation.

In every case it remains necessary for clients and servers to be
configurable as to which TLS ciphersuites are acceptable.

Keith

---

From: Carl-Uno Manros <[email-masked]>
Date: Wed, 7 Jan 1998 10:12:53 PST

When trying to apply TLS to our IPP scenarios, we have run into a few
questions relating to TLS and URI schemes and port numbers. We had had this
discussion going on for many months already on the IPP DL, and I am now
trying to see if I can get some additional input from the TLS DL.

It seems that the overall TLS draft specification (version 5) is silent on
TLS's use of schemes and port numbers apart from discussing in Annex E that
TLS might share the "https" scheme and port 443 with SSL3, when both are
supported.

The same question goes for the use of port numbers. E.g. should you still
use port 80 for the combination of HTTP and TLS (Annex E seems to suggest
that you use port 443 as for SSL3)?

BTW, how is the draft on a TLS profile for HTTP coming along? Anybody
started work on that yet? It seems that these questions need to be
addressed in that draft.

We need some authoritative answers on this in order to finalize our IPP
specifications.

Hope that somebody can help clarify what the rules of the game is here.

Carl-Uno
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]

---

From: Jeff Williams <[email-masked]>
Date: Wed, 07 Jan 1998 23:37:00 +0000

Keith and all,

> to propagate this mechanism to new protocols.

  Yes, indeed this is a wise policy to persue.

>   if someone defines a means of negotiating security in-band over

  Again this is awise approach.  In our "Intergration Facility or (MLPI) we
provide for this option.

>   an "ipp:" URL scheme defined, which defaults to that port.

  Not necessary if you use and intergration scheam or facility to
provide for multipul port configuration.

>   layer) or whether it uses in-band negotiation.

  Hummmmm? intresting conclusion or answer.  But it would again seem
unecessary if integration for IPP on multipul ports using stacked protocols
or multi=leyer approach for cyphers.

> configurable as to which TLS ciphersuites are acceptable.

  Agreed.  But this should not necessarly be a configuration restriction.

> Keith

Regards,