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

[Eric Rescorla <[e-mail]>]

On Mon, Jan 31, 2011 at 2:11 PM, Eliot Lear <[e-mail]> wrote:
> 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.

Really? What fraction of the port space has been consumed?


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

I didn't say it did, if you reread my message. What I said was that
not negotiating
addresses downgrade.


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

Well, I'm not sure I see the relevance of this. The question is how
the server supports
both secure and insecure variants at once.




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

Well, I have no idea what protocol you're thinking of, but all of the
upward negotiation
protocols have a significantly more complicated state machine than does HTTPS.


>but there now is a whole lot of free
> code out there that does just this.

And it's generally all protocol specific, so we have this problem with
every new protocol.


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

Of course. Which is why I'm not saying that you should ALWAYS do a
separate port.
But I don't agree there is consensus that it's bad either.