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

From: EKR <[email-masked]> (by way of Carl-Uno Manros <[email-masked]>)
Date: Wed, 7 Jan 1998 15:52:02 PST

FYI,

This is first reply I got back on my enquiry to the TLS DL.

Carl-Uno

EKR <ekr> writes:
Carl-Uno Mamros writes:
> 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.

That was my intention. Since TLS/SSL3 implementations can transparently
negotiate a common protocol, this seems ok--and it avoids further
proliferation of ports. Anyone have other opinions.

It's important to distinguish between the two HTTP/TLS drafts in progress.
The one that I'm working on describes current practice for HTTP over
SSL, extending it to TLS. I understand that Rohit Khare is working
on a draft that allows (the more principled thing) HTTP implementations
to negotiate to HTTP/TLS over the common HTTP port.

Everything in this message, then, refers to the draft that I'm
working on.

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

That's current practice.

> Do you see any reasons to allocate new schemes and/or port numbers for IPP
> (differently from HTTP) when using HTTP as transport?

I'm not very familiar with IPP. If IPP runs over HTTP, you should
be able to use the same port numbers. 

> BTW, how is the draft on a TLS profile for HTTP coming along?

I've got a rough draft. There turn out to be some issues that
impact TLS in general, that I'd like to to iron out before
sending it off.

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

---

From: Carl Kugler <[email-masked]>
Date: Thu, 8 Jan 1998 16:03:26 -0500

> IPP clients should use "https:", without overriding the port #,
  > to indicate they want to talk to an IPP server on port 443.

I'm a little confused about what it means for an IPP client to "override the
port #".  The port is what the client connects to, but as far as I know the
number isn't passed in the HTTP or IPP protocols, right? The client has to
connect to some port; should it be 443 or 80 in this case?

-Carl Kugler

        [email-masked]
        01/07/98 12:03 PM
Please respond to [email-masked] @ internet

To: [email-masked] @ internet
cc: [email-masked] @ internet, [email-masked] @ internet,
[email-masked] @ internet, [email-masked] @ internet
Subject: IPP> Re: URI scheme and port numbers for TLS

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

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