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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----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-----
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]