-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/30/09 10:45 AM, Joseph Salowey (jsalowey) wrote: > > >> -----Original Message----- >> From: Simon Josefsson [mailto:si...@josefsson.org] >> Sent: Tuesday, September 29, 2009 10:20 PM >> To: Joseph Salowey (jsalowey) >> Cc: Michael D'Errico; martin....@sap.com; ietf@ietf.org; t...@ietf.org >> Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis >> (Transport Layer >> >> "Joseph Salowey (jsalowey)" <jsalo...@cisco.com> writes: >> >>> It seems that this is really up to the application. Both >> server names >>> are authenticated under the same session. It seems an application >>> server may require them to be the same or allow them to be >> different. >> >> I would agree if the draft wouldn't prevent clients from >> requesting a different server name at the application layer: >> >> negotiated in the application protocol. If the server_name is >> established in the TLS session handshake, the client SHOULD NOT >> attempt to request a different server name at the >> application layer. >> >> At least that is how I read it. >> > [Joe] Good point, however I still think it is application protocol that > needs to enforce the matching if it cares. Perhaps we can add some text > that states > > "Since it is possible for a client to present a different server_name in > the application protocol, application server implementators should take > this into account and take appropriate action to avoid introducing > security vulnerabilities if the names do not match. "
I think that text is helpful. Overall, however, I wonder if this is something that truly belongs in rfc4366bis or if it is more appropriate to define a set of best practices for application protocols that use TLS. A group of folks in the Apps Area has started to do that here: http://tools.ietf.org/html/draft-saintandre-tls-server-id-check It can't hurt to place a brief warning in the core TLS spec, though. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrDjI4ACgkQNL8k5A2w/vxLJwCgq4KOjJg17NEY0YpvNG2AL2yu 9HYAn3mYXXYY68hQmh+mJ8NxIsZ5XRMa =GdPy -----END PGP SIGNATURE----- _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
