On Sat, Oct 10, 2015 at 05:11:56PM -0400, Dave Garrett wrote:
> Note that opportunistic encryption is weird and getting
> the whole document to be perfect for it might not be entirely doable, as
> OE needs to tolerate more fuzziness than the main spec should allow.
Unfortunately requirements in the base TLS document end up "set in
stone" in software implementations, and then break opportunistic
TLS in ways application software can't work around.
So while the UTA TLS BCP can write requirements that exclude
opportunistic security, the TLS specification does not have
that liberty.
In this case the solution is simple enough. DO NOT prohibit
the exchange of certificate chains with SHA-1 in them. Just
prohibit *trusting* their content.
We alredy have language to allow servers and client to send
"last-resort" chains that don't match the peer's advertised supported
algorithms. This suffices.
The necessary changes are then MUCH simpler than the current pull
request 287.
* Prohibit advertising SHA-1 in the supported algorithms list,
(except as needed for TLS 1.2 compat, ...)
* Prohibit trusting SHA-1 when found in certificates that are
not self-signed.
That's it. A lot less work. SHA-1 is no longer trusted, but does
not impede interoperability when certificates are largely useless
baggage.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
