Subject: [Uta] Port 465

From: "Salz, Rich" <[email-masked]>
Date: Fri, 7 Mar 2014 05:33:24 -0500

Some info.  It's a pub-sub protocol for limited multicast used by cisco routers.

http://www.idonotes.com/IdoNotes/idonotes.nsf/dx/08172006023221PMCMIQT4.htm (note the date tho)
http://www.cisco.com/c/en/us/td/docs/ios/12_2/ip/configuration/guide/fipr_c/1cfssm.html

--
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Chris Newman <[email-masked]>
Date: Fri, 07 Mar 2014 11:38:54 +0000

> Some info.  It's a pub-sub protocol for limited multicast used by cisco
http://www.idonotes.com/IdoNotes/idonotes.nsf/dx/08172006023221PMCMIQT4.htm 
(note the date tho)

Here's the current text on this topic in draft-newman-email-deep:

----
   IANA is asked to assign an alternate usage of port 465 in addition to
   the current assignment using the following template ([RFC6335]):
...
   This is a one time procedural exception to the rules in RFC 6335.
   This requires explicit IESG approval and does not set a precedent.
   Historically, port 465 was briefly registered as the "smtps" port.
   This registration made no sense as the SMTP transport MX
   infrastructure has no way to specify a port so port 25 is always
   used.  As a result, the registration was revoked and was subsequently
   reassigned to a different service.  In hindsight, the "smtps"
   registration should have been renamed or reserved rather than
   revoked.  Unfortunately, some widely deployed mail software
   interpreted "smtps" as "submissions" [RFC6409] and used that port for
   email submission by default when an end-user requests security during
   account setup.  If a new port is assigned for the submissions
   service, email software will either continue with unregistered use of
   port 465 (leaving the port registry inaccurate relative to de-facto
   practice and wasting a well-known port), or confusion between the de-
   facto and registered ports will cause harmful interoperability
   problems that will deter use of TLS for message submission.  The
   authors believe both of these outcomes are less desirable than a wart
   in the registry documenting real-world usage of a port for two
   purposes.  Although STARTTLS-on-port-587 has deployed, it has not
   replaced deployed use of implicit TLS submission on port 465.
----

I welcome discussion and socialization to port registry folks.

		- Chris

---

From: Eliot Lear <[email-masked]>
Date: Fri, 07 Mar 2014 13:06:31 +0000

Hi Chris,

I did some quick checking with Toerless, who is the contact.  The port
is assigned for a specific use, which is URD, a transitional technology
for IGMPv2/IGMPv3 & SSM.  Cisco currently supports the use of the
protocol, and perhaps as important, it is used as an intercept for *any*
destination IP address on that port when URD is enabled.

Eliot

On 3/7/14, 11:38 AM, Chris Newman wrote:
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 7 Mar 2014 20:31:09 +0200

> destination IP address on that port when URD is enabled.

So one can't use port 465 if URD is enabled on any port on the path?
Is this just UDP? Or also TCP?

-Ilari

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 8 Mar 2014 11:33:37 -0800

>  replaced deployed use of implicit TLS submission on port 465.

Updating mail agents to use another port is of course possible, but in
practice will require manual configuration of each and every agent. It would
have to be synchronized between servers and clients, which makes automated
updates pretty hard. In short, any drastic action is likely to disrupt the
deployment of SMTP Submission over TLS. We are trying to get more
disruption, not less, so we should not mandate a change of port on a large
number of deployed clients and servers.

The port collision is only a practical problem if the same server wants to
deploy both Secure SMTP submission and the experimental "URL Rendesvous
(sic) Directory for SSM." Do we know whether that is a problem in practice?
I suspect that the overlap between the two usages is quite small, and that
if any port migration is required, it will only concern a small number of
servers deploying both services.

Given that, it is probably better that the IANA directory recognizes usage.
IANA should document that traffic on TCP port 465 can be either of those
protocols. Or alternatively, mark TCP 465 as "reserved" and just pick a
different port for SSM...

-- Christian Huitema

---

From: t.p. <[email-masked]>
Date: Sun, 9 Mar 2014 10:01:45 +0000

----- Original Message -----
From: "Christian Huitema" <[email-masked]>
To: "'Chris Newman'" <[email-masked]>; "'Salz, Rich'"
<[email-masked]>; <[email-masked]>
Sent: Saturday, March 08, 2014 7:33 PM
> number of deployed clients and servers.

Christian,

My ISP, not a small one, required me and everyone else to change their
ports a few years ago.  There was parallel running, so it did not have
to be synchronised between clients and servers.  I would imagine the
numbers affected would be in seven figures. We had no choice, so it
happened.  (Interestingly, the ISP provided instructions on how to make
the change but got it wrong, so some SMTP skills were needed to make the
migration).

Tom Petch

---

From: Eliot Lear <[email-masked]>
Date: Mon, 10 Mar 2014 07:51:40 +0100

[Message fail- resending]

On 3/8/14, 8:33 PM, Christian Huitema wrote:
> (sic) Directory for SSM."

Routers running URD intercept all packets using port 465, regardless of
destination.

Eliot

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Mar 2014 03:01:12 -0400

On 03/10/2014 02:51 AM, Eliot Lear wrote:
> Routers running URD intercept all packets using port 465, regardless 
> of destination.

So is the right thing to do:

a)  Recommend port 465 anyway, but document the problem with these routers?

b)  Allocate and recommend a different port, even though that's going to 
increase configuration difficulties for the vast majority of legacy 
clients? (and assuming that new clients default to the new port, also 
complicate configuration of those clients with legacy servers?)

c) Allocate a different port to be the "official" port, recommend that 
servers support both ports when feasible (for the benefit of legacy 
clients), and recommend that new clients use SRV lookup to discover the 
submissions port?

d) something else?

Keith

---

From: Kurt Andersen <[email-masked]>
Date: Mon, 10 Mar 2014 07:21:44 -0700

On Monday, March 10, 2014, Keith Moore
<[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>

> a)  Recommend port 465 anyway, but document the problem with these routers?

I think that the right thing would be to have Cisco move and keep 465 for
smtps. It's much more likely that one vendor can/will change than that we
can get a decentralized mail usage to change on both provider and consumer
sides.

--Kurt Andersen

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Mar 2014 10:26:32 -0400

Sent from my iPhone

> On Mar 10, 2014, at 10:17 AM, Kurt Andersen <[email-masked]> wrote:
> 
>> On Monday, March 10, 2014, Keith Moore <[email-masked]> wrote:
>>> Routers running URD intercept all packets using port 465, regardless of destination.
>> 
> I think that the right thing would be to have Cisco move and keep 465 for smtps. It's much more likely that one vendor can/will change than that we can get a decentralized mail usage to change on both provider and consumer sides.

Somehow that doesn't seem very workable to me.  Anyone who knows that protocol who can comment in more detail?  I take it that it's not just a matter of upgrading all of the routers (which would be difficult enough) but also some host based software?

---

From: Tony Finch <[email-masked]>
Date: Mon, 10 Mar 2014 14:32:12 +0000

> a)  Recommend port 465 anyway, but document the problem with these routers?

The current use of port 465 for message submission should be documented,
but MUAs should be recommended to use STARTTLS on port 587 instead. They
are generally following this recommendation already.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Dover, Wight: North veering northeast 4 or 5, increasing 6 or 7 for a time.
Slight, becoming moderate or rough. Mainly fair. Moderate or good,
occasionally poor.

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 10 Mar 2014 08:20:21 -0700

On  Sunday, March 9, 2014 11:52 PM, Eliot Lear wrote

> Routers running URD intercept all packets using port 465, regardless of

That particularity of the URD design seems to be the root of the problem. It
assumes that port numbers have global meaning, when the practice has always
been that port numbers are locally assigned by host systems. Yes, there is
an IANA registry, but its practical use is advisory, a convenience, not a
hard coded rule of the Internet. I suppose that the IAB could have an
interesting debate on this subject.

The net result is that URD is hard to deploy, because ISP will presumably be
reluctant to break secure mail traffic and receive the corresponding amount
of support calls. If I was responsible for that product, I would explore
design changes that minimize the issue. For example, using some form of IP
anycast address, so the routers only have to intercept the packets that are
meant to be intercepted. Or maybe put some kind of signature in the packet,
like a TCP option that asks to "intercept me." Or a specific source port.
There has to be a way to minimize the problem...

-- Christian Huitema

---

From: Eliot Lear <[email-masked]>
Date: Mon, 10 Mar 2014 16:30:16 +0100

Christian,

On 3/10/14, 4:20 PM, Christian Huitema wrote:
> That particularity of the URD design seems to be the root of the problem. 

No.  The root of the problem is that there are two services using the
same port.

Eliot

---

From: t.p. <[email-masked]>
Date: Mon, 10 Mar 2014 15:41:25 +0000

----- Original Message -----
From: "Kurt Andersen" <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 10, 2014 2:21 PM
> On Monday, March 10, 2014, Keith Moore
<[email-masked]<javascript:_e(%7B%7D,'cvml','moore@network-h
eretics.com');>>
> can get a decentralized mail usage to change on both provider and
consumer

Right thing legally but the wrong thing engineering-wise.

We have change control over smtps and so can hope to influence its
specification.

Tom Petch

> --Kurt Andersen

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

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Mar 2014 12:00:23 -0400

> are generally following this recommendation already.

I would actually like to discourage use of cleartext ports and 
STARTTLS.   I believe the desirable end-state for all email protocols is 
to always use Implicit TLS; which is both simpler and more secure.   
Clearly both clients and servers will still need to be configurable to 
support port 587 and STARTTLS for some time for interop with legacy 
servers and clients, respectively, but I think this should be phased out 
over time, and the standard / "MUST implement" practice should be 
Implicit TLS on a well-known port.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Mar 2014 12:34:26 -0400

> No.  The root of the problem is that there are two services using the

I don't think it matters how we state the "root of the problem". The 
problem seems to be that even though there's widespread use of port 465 
for SMTPS, there is also a widespread conflicting use that is officially 
associated with that port, and there's really no way that the two can 
coexist gracefully.

So we really need to use a different port for SMTPS.

Keith

---

From: Kurt Andersen <[email-masked]>
Date: Mon, 10 Mar 2014 16:04:30 -0700

> I don't think it matters how we state the "root of the problem". The
problem seems to be that even though there's widespread use of port 465 for
SMTPS, there is also a widespread conflicting use that is officially
associated with that port, and there's really no way that the two can
coexist gracefully.
> So we really need to use a different port for SMTPS.

I'd be interested to know how 465 was "taken away" from smtps without
sufficient notice to the community. I still think it is the right approach
to move urd rather than smtps. Has anyone asked Cisco about it?

--Kurt Andersen

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Mar 2014 21:19:17 -0400

On 03/10/2014 07:04 PM, Kurt Andersen wrote:
> sufficient notice to the community. I still think it is the right 
> approach to move urd rather than smtps. Has anyone asked Cisco about it?

If anyone, we should ask IANA; they should have records of what happened 
and why.  Though I think some of the WG members probably know the story.

Note that 465 for smtps was never standardized; I believe it was a 
private registration.  So "the community" didn't own it.

Keith

---

From: Kurt Andersen <[email-masked]>
Date: Mon, 10 Mar 2014 19:07:00 -0700

On Mon, Mar 10, 2014 at 6:19 PM, Keith Moore <[email-masked]>wrote:

> Note that 465 for smtps was never standardized; I believe it was a private
> registration.  So "the community" didn't own it

For never having been standardized, it certainly appears in a lot of
Unix/Linux distros. For instance on Redhat 6:

     urd             465/tcp         smtps   # URL Rendesvous Directory for
SSM / SMTP over SSL (TLS)

Note the multiple assignment is noted but not "revoked".

--Kurt

---

From: Chris Newman <[email-masked]>
Date: Mon, 10 Mar 2014 19:54:03 +0000

> clients), and recommend that new clients use SRV lookup to discover the

I don't think there's a "right thing" to do in this situation. I am opposed 
to registering a new well-known-port for "submissions"; that will create 
real interoperability and deployment problems for no benefit other than 
registry purity. So I do not support options b & c. Here are three options, 
in my order of preference, that I do not believe make things worse than 
they are today:

1. Recommend port 465, but document the problem with these routers.

2. Recommend use of STARTTLS on port 587. This makes our Submission + TLS 
recommendation asymmetric with our recommendation for other MUA protocols, 
but it does not make the current deployment situation worse. STARTTLS 
remains the only option for SMTP relay, so it could be argued this keeps 
SMTP consistent. However, STARTTLS does seem to be somewhat more difficult 
to deploy/test/configure than implicit TLS in practice so I believe option 
1 will result in more use of TLS for submission than this option.

3. Do not register a new well-known-port for "submissions". Clients wishing 
to use "submissions" service MUST use SRV record lookups as documented RFC 
6186. Choice of port is a matter for service providers. This will be more 
difficult to deploy than 1, particularly because it requires SRV-ID (or 
DANE) support and has near zero deployment today.

I prefer 1, but can live with any of these three options.

		- Chris

---

From: Chris Newman <[email-masked]>
Date: Mon, 10 Mar 2014 19:25:42 +0000

--On March 10, 2014 16:04:30 -0700 Kurt Andersen <[email-masked]> wrote:
> sufficient notice to the community.

You are incorrect about that "sufficient notice" assumption.

See appendix C:
 http://tools.ietf.org/html/draft-hoffman-smtp-ssl-08

I believe I suggested the idea of deprecating "smtps" so blame me if you 
want to blame someone. I don't recall who wrote the fateful text. The 
document passed through IETF consensus and there was a two year period 
before the problem was created, assuming that was the final text IANA 
implemented. There was a solid IETF consensus at the time in favor of 
STARTTLS, and we failed at the time to realize that while "smtps" is a 
design error, "submissions" is perfectly reasonable. Unfortunately many 
implementers shipped software that used the "smtps" port as "submissions".

		- Chris

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Mar 2014 00:52:57 -0400

On 03/10/2014 03:54 PM, Chris Newman wrote:
> --On March 10, 2014 3:01:12 -0400 Keith Moore 
> <[email-masked]> wrote:
> I don't think there's a "right thing" to do in this situation. I am 
> opposed to registering a new well-known-port for "submissions"; that 
> will create real interoperability and deployment problems for no 
> benefit other than registry purity. So I do not support options b & c. 
> Here are three options, in my order of preference, that I do not 
> believe make things worse than they are today:
>
> 2. Recommend use of STARTTLS on port 587. This makes our Submission + 
> TLS recommendation asymmetric with our recommendation for other MUA 
> protocols, but it does not make the current deployment situation 
> worse. STARTTLS remains the only option for SMTP relay, so it could be 
> argued this keeps SMTP consistent. However, STARTTLS does seem to be 
> somewhat more difficult to deploy/test/configure than implicit TLS in 
> practice so I believe option 1 will result in more use of TLS for 
> submission than this option.
>
> 3. Do not register a new well-known-port for "submissions". Clients 
> wishing to use "submissions" service MUST use SRV record lookups as 
> documented RFC 6186. Choice of port is a matter for service providers. 
> This will be more difficult to deploy than 1, particularly because it 
> requires SRV-ID (or DANE) support and has near zero deployment today.

I suspect it's really useful to have a well-known port for submissions 
so that paranoid network admis / network access providers can punch 
holes in their "deny all outgoing" filtering rules to accommodate mail 
submission.  I seem to recall that one of the reasons we wanted a 
separate submission port in the first place (not the only one, surely) 
was widespread blocking of port 25, but at least a few network providers 
seem to be really aggressive about blocking of outbound traffic other 
than obviously safe/necessary ports.

And it might actually be this kind of port blocking that is the biggest 
reason to continue using port 587, since it's been around long enough, 
and advertised as being for mail submission, long enough to have holes 
punched for it.

Keith

---

From: t.p. <[email-masked]>
Date: Tue, 11 Mar 2014 10:24:22 +0000

----- Original Message -----
From: "Chris Newman" <[email-masked]>
To: "Keith Moore" <[email-masked]>; <[email-masked]>
Sent: Monday, March 10, 2014 7:54 PM
> --On March 10, 2014 3:01:12 -0400 Keith Moore
<[email-masked]>
> I don't think there's a "right thing" to do in this situation. I am
opposed
> 2. Recommend use of STARTTLS on port 587. This makes our Submission +
TLS
> 3. Do not register a new well-known-port for "submissions". Clients
wishing
> I prefer 1, but can live with any of these three options.

In terms of getting from where we are to where we want to be, ports are
realistically the only option, for anything that affects the end user
with their PC.

All the PCs I have had to configure have allowed me to put in a port of
my choosing whereas if they were not shipped with a STARTTLS or SRV-ID
option, then it is unlikely to happen soon (or ever).  Last I saw 20% of
users accessing web sites were on Windows XP - out of currency 8th April
2014 - so anything requiring a software upgrade is likely to involve a
migration lasting a decade.

Tom Petch

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Mar 2014 08:40:55 -0400

> migration lasting a decade.

I agree that we should expect a long-term migration before all users are 
safely out of the worst combinations of user-agent, configuration, 
TLS/SSL implementation, etc.   I don't think that should  change what we 
recommend as best or standard practice.  But we need to realize that 
both clients and servers that conform to the new standards will need to 
be configurable to interoperate with servers and clients (respectively) 
that are in use today, for many years to come.

For example, this means that servers that meet our recommendations are 
going to need to be configurable to support RC4, old versions of TLS, 
STARTTLS, deprecated/disfavored ports (if we decide that there are any), 
old certificate subject name conventions, and even cleartext, for some 
time.   And the situation is almost as bad for clients that meet our 
recommendations, but hopefully such clients will "latch" better 
capabilities as they become available, stop using these protocols and 
ciphersuites for existing configurations, and warn users about 
establishing new configurations that use them.

Keith