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 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
