On Sat, Nov 04, 2006 at 01:21:55PM +1300, Peter Gutmann wrote:
> <Pasi.Eronen@nokia.com> writes:

>> RFC 4279 does have "DHE_PSK" suites (Diffie-Hellman authenticated with a PSK;
>> nothing anonymous there). Is this what you meant by DH_anon_PSK, or something
>> else?

> Sort of.  It's a naming problem, the main TLS spec uses 'DH_anon' to mean 'key
> exchange without certificates', while the TLS-PSK spec uses 'DHE_PSK' to mean
> 'key exchange without certificates (but with mutual authentication via PSK)'
> (re-reading my earlier posting, I was pretty unclear on this :-).  My concern
> was that phrasing the authentication check purely as "verifying the
> certificate" (as in, for example, Bodo's suggested text) would cause problems
> if that were taken to apply to the PSK suites (and SRP and others) where
> there's no certificate to verify.  [...]

So here's an updated proposal.  This avoids the word "deprecated" (as by
Pasi's and Simon's earlier remarks), and avoids the word "certificate":

   The following cipher suites are used for completely anonymous Diffie-
   Hellman communications in which neither party is authenticated. Note
   that this mode is vulnerable to man-in-the-middle attacks.  Using
   this mode therefore is of limited use: These ciphersuites MUST NOT be
   used by TLS 1.2 implementations unless the application layer has
   specifically requested to allow anonymous key exchange.  (Anonymous
   key exchange may sometimes be acceptable, for example, to support
   opportunistic encryption when no set-up for authentication is in
   place, or when TLS is used as part of more complex security protocols
   that have other means to ensure authentication.)

    CipherSuite TLS_DH_anon_WITH_RC4_128_MD5           = { 0x00, 0x18 };
    CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA           = { 0x00, 0x1A };
    CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00, 0x1B };
    CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA       = { 0x00, 0x34 };
    CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA       = { 0x00, 0x3A };

   Note that using non-anonymous key exchange without actually verifying
   the key exchange is essentially equivalent to anonymous key exchange,
   and the same precautions apply.  While non-anonymous key exchange
   will generally involve a higher computational and communicational
   cost than anonymous key exchange, it may be in the interest of
   interoperability not to disable non-anonymous key exchange when the
   application layer is allowing anonymous key exchange.

Bodo

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls