On 11 Feb 2014, at 15:52 , Joe Touch <[email protected]> wrote: >> I'd say is not only performance, but a security optimization. Unless >> the server is sure that starting a TLS session is explicitly required by >> the client, how can a server know whether there has been an intentional >> downgrade by a man-in-the-middle? > > It cannot, but let's look at the case where there are different ports. The > MITM in that case can rewrite packets to the different port. Same problem. > > The conclusion is that the server cannot know about the downgrade until the > connection fails because the MITM can't spoof the server's TLS credentials > back to the client.
Granted. But relaying a security decision at one layer of the combination of other unrelated options at another supporting layer seems an unnecessary complication, and that is against good security practice. > > Furthermore, the client and server >> codes become completely independent of what happens at the TCP layer, >> and I think this is in general a good design practice. > > Ports are a critical global community resource, not a programming convenience. If this the gist of your argument on the additional port issue, I can understand it. And if restricting the allocation of specific ports is a common view within the community we could address the solution based on a specific command. >> And even if you find counterarguments to the two reasons above, the >> common practice is the use of either a dedicated port or a dedicated >> command. > > We should be aiming for best practice, not common practice. I am afraid I do not see why intertwinning two layers is a best practice... >> And that implies that developers will find plenty of choices to >> implement this, widely validated and understood by the community. And >> when it comes to security, this is of great value, mostly when PCEP peer >> developers will not usually be security experts. > > Agreed, but they need to be protocol experts or they won't get the protocols > right. If they do get the protocols right, then they can trivially determine > the type of connection - at connection start - simply from the configuration > of keys. From information derived from another layer they should not be concerned with. If there were no other feasible choices, I'd go for it. But there are, with wide support and thorough scanning for security flaws. >> We are talking about >> independent layers, or am I missing something? FWIW, you could use any >> of them on an IPsec connection as well... > > You could, but they should all fail except the ones that you specify. That's > a basic tenet of security design. > > This is why I concluded that the protocol specifications - existing and the > one currently under review - are easily distinguished. Ports are assigned for > current use, not potential future use. > > So unless you're proposing to revise the doc to include these other cases, > they're irrelevant. And if you are, we can then talk about whether it's good > security design to consider so may alternatives without specific use cases in > mind. The document is revised (in version -01) to say that TCP protection mechanisms and TLS usage are orthogonal, so I don't see the need to consider all or any of the alternatives that arise from their combination >>> There are no protocol changes required to make this happen; you >>> just need to use the information you already have. >> >> By not having TCP protection and TLS orthogonal we are mixing >> securitymechanisms at two different layers, and assuming there is some kind >> of >> cross-layer exchange that may not necessarily happen because is out of >> the common practice, and that is a recipe for security holes. > > TCP is - and needs to be - aware of both TCP and TLS protection. It has to > have all the information needed anyway. TCP should be totally oblivious to the fact TLS is used above it, in the same sense that TLS is oblivious to the particular TCP options in use. And the same happens with PCEP with respect to both of them. >> Maybe that the current writing of the PCEPS draft is not clear >> enough in that respect. We would really appreciate any suggestion in > improving it. > > If you intend the protections to be orthogonal, you need to say that, and you > need to justify why all possible combinations are needed. At that point I > would argue against that set of combinations. As I said before, in version -01 orthogonality is declared. And since they are declared orthogonal I don't see the need for analyzing the different combinations, for the same reason I don't see the need of discussing about running PCEPS on public or private IP addressing, to give an example. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: [email protected] Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
