ietf
[Top] [All Lists]

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

2011-01-31 16:21:33
On Mon, Jan 31, 2011 at 2:11 PM, Eliot Lear <lear(_at_)cisco(_dot_)com> 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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>