If opportunistic TLS handshakes need to be indistinguishable from server-authenticated TLS handshakes, then perhaps opportunistic clients have no choice but to send the signature_algorithms extension (when offering TLS1.2). The absence of signature_algorithms in a TLS 1.2 ClientHello can be used as a signal by the MITM.
-----Original Message----- From: Martin Thomson [mailto:martin.thom...@gmail.com] Sent: Tuesday, July 14, 2015 12:56 PM To: Andrei Popov Cc: tls@ietf.org Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) On 14 July 2015 at 12:30, Andrei Popov <andrei.po...@microsoft.com> wrote: > The downside is of course that the attacker can easily distinguish > opportunistic clients from server-authenticating ones. Is this a concern for > the opportunistic TLS community? I raised the concern about this previously. Opportunistic MitM happens, and providing a strong signal that the connection won't be (or couldn't be) authenticated somehow is a problem for that. I'd rather have opportunistic security be indistinguishable from "real" security. It also means that you don't have separate code paths to support. The anonymous modes serve a different purpose. For instance tcpinc could use them. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
