> On Friday, July 24, 2015 01:18:41 pm Hubert Kario wrote:
>> On Friday 24 July 2015 12:57:42 Dave Garrett wrote:
>>> To be clear, the wording I have in the PR is not this broad. It only
>>> requires aborting if export ciphers were offered by a TLS 1.3+ client, not
>>> just any client.
>>
>> and how a server can tell that the client is TLS1.3 only and not
>> TLS1.0-up-to-
>> TLS1.3?
>
> TLS 1.0-1.3 shouldn't be offering export ciphers any more than TLS 1.3 only.
> A TLS 1.0-1.2 client, or at least one offering that, is what it would not
> complain about.
>
> For the rare case of "legitimate" use of export ciphers, namely spiders,
> it'll need a fallback attempt with a full set of suites. Export ciphers are
> not something we should be accounting for allowance of in any protocol we
> want to claim to be secure.
>
> We do have to remember that even _offering_ them is dangerous, even if
> they're not negotiated. It's dangerous to even _support_ them, even if not
> offering. Having this in any way presents an unacceptable attack surface for
> a MitM to try and find a way to confuse implementations into using them. If
> all implementations were perfect, yeah, this wouldn't be a problem. History
> has shown this is not the case. :(
Personally, I don't think this is worth the effort. You'd need a full list of
EXPORT cipher hardcoded, and there are also EXPORT1024 ciphers not in the
cipher suite registry but less dangerous. It is rare for current TLS 1.2
clients to offer export ciphers either, and most practical attacks are
prevented by disabling them on the server side.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
