ietf
[Top] [All Lists]

Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer

2009-09-30 13:55:00
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(_at_)stpeter(_dot_)im> 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(_at_)josefsson(_dot_)org]
Sent: Tuesday, September 29, 2009 10:20 PM
To: Joseph Salowey (jsalowey)
Cc: Michael D'Errico; martin(_dot_)rex(_at_)sap(_dot_)com; 
ietf(_at_)ietf(_dot_)org; tls(_at_)ietf(_dot_)org
Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis
(Transport Layer

"Joseph Salowey (jsalowey)" <jsalowey(_at_)cisco(_dot_)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-----
_______________________________________________
TLS mailing list
TLS(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/tls

-- 
Regards,
Uri         uri(_at_)ll(_dot_)mit(_dot_)edu
<Disclaimer>

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf