* Travis Burtrum <tra...@burtrum.org> [2015-11-05 20:56]: > That was a deliberate decision on my part, and does not affect > security in the way you mentioned because I explicitly state: > > TLS certificates MUST be validated the same way as for STARTTLS. > (ie, as specified in XMPP Core).
So lets assume I want to connect as ge...@example.com and the SRV record is _xmpp-client._tls.example.com. IN SRV 5 1 443 xmpp.example.com. My client then makes a TCP connection to xmpp.example.com:443, requests xmpp.example.com via SNI, and the server is expected to return the certificate for example.com instead, which the client verifies? If this is the desired behavior, it must be stated VERY CLEARLY in the XEP, as it is very unintuitive. Furthermore, this would require the server to not only have mappings from service domain -> certificate file, but also from SNI host to service domain (and then implicitly to certificate file). At least such a behavior is not contrary to RFC 6066: | A server that receives a client hello containing the "server_name" | extension MAY use the information contained in the extension to guide | its selection of an appropriate certificate to return to the client, | and/or other aspects of security policy. Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || ++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: Digital signature
