Re: Last Call: <draft-ietf-tsvwg-iana-ports-09.txt> (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

[Eliot Lear <[e-mail]>]

Eric,
> Clearly, if you're going to do a negotiation design you want a single port.
> If you're going to do a non-negotiated design, then I don't see a huge
> amount of value in using a single port. It's true that there is a port
> consumption issue, but OTOH ports are there for protocol demuxing and
> this is clearly another protocol.

Another way to look at this is that it's the same protocol running atop
a security layer.  Same protocol engine, perhaps in a slightly different
security context in terms of what is authorized.  And there's good
reason to look at it this way.  Aside from the leverage it gives
reviewers as I discussed previously, there's also the minor matter of
port consumption, which won't be so minor if we run short.  And don't
think that can't happen.  Additional ports are being approved for
reasons that are clearly architecture limitations.  I'm not even sure
this is an acceptable excuse.

For one, if we look at some of the examples that have been mooted, I
doubt that an additional port would have solved the downgrade problem. 
The case I have in mind is indeed SMTP.  The conditions that allow for
the downgrade attack have more to do with the realities of certificate
management than STARTTLS.

As I wrote in a different context there is also the draft that Paul has
written for HASTLS, which allows a server to express a policy without
having to require a port.  While some of us have some questions about
some of the choices Paul made in the design, on the whole I think
everyone agrees it's a good idea.  It may not, however, solve the entire
problem, because we now are forced to answer the question as to how host
policy should be conveyed.

>  It's simply a lot easier to have
> your TLS stack just start its thing rather than try to autodetect
> whether you have TLS or some other protocol.

Maybe so (wasn't so hard for me), but there now is a whole lot of free
code out there that does just this.



>  So I would generally push
> back on the claim that non-negotiated designs should have to have
> demuxing in information in the dataflow rather than use the port.

There is a cost that extends beyond the protocol.  That has to be taken
into account.

Eliot