I think this text is helpful and does belong to RFC 4366bis. TLS is a tool. This is a piece of information how to avoid a pitfall when using this tool. Which does not preclude from writing a lengthier document - a guide for application developers. On 9/30/09 12:51 , "Peter Saint-Andre" <stpeter@xxxxxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 9/30/09 10:45 AM, Joseph Salowey (jsalowey) wrote: >> >> >>> -----Original Message----- >>> From: Simon Josefsson [mailto:simon@xxxxxxxxxxxxx] >>> Sent: Tuesday, September 29, 2009 10:20 PM >>> To: Joseph Salowey (jsalowey) >>> Cc: Michael D'Errico; martin.rex@xxxxxxx; ietf@xxxxxxxx; tls@xxxxxxxx >>> Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis >>> (Transport Layer >>> >>> "Joseph Salowey (jsalowey)" <jsalowey@xxxxxxxxx> 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----- > _______________________________________________ > TLS mailing list > TLS@xxxxxxxx > https://www.ietf.org/mailman/listinfo/tls -- Regards, Uri uri@xxxxxxxxxx <Disclaimer> _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf