Hi Joe, Too much travel making my email backlog grow, I'm afraid...
On 6 Feb 2014, at 22:41 , Joe Touch <[email protected]> wrote: >> The rationale is the common practice derived from the TLS layered >> approach, so a client knows how and when require the server to start a >> TLS connection, and the server knows in advance what the client is >> requiring and match it against its policy. > > That is common when there is no other way to determine whether a connection > uses TLS or not (and even then is at best a performance optimization). 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? 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. 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. 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. > The use of TCP protection must be orthogonal to the use of TLS, so it >> can not be used for the server making a guess of the protocol >> security encapsulation. > > TCP protection isn't orthogonal to TLS for pcep as currently specified; see > the table above. The only connections that can use TLS would be those that do > not use TCP MD5 (see the list of cases above). > >> Either we have a protocol-specific mechanism (a-la-STARTTLS) or we >> usea specific port. > ... > > For every connection, you already know the mode before the connection starts. > If the connection is configured to require TCP MD5, then there is no TLS. If > not, then there must be TLS. What I cannot see is why the combination of TCP MD5 with TLS could not happen, or the combination of TCP AO without TLS. We are talking about independent layers, or am I missing something? FWIW, you could use any of them on an IPsec connection as well... > 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 security mechanisms 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. 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. 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
