> The problem with this is that the standard hash API is { Init, [ Update,
> Update, ... ], Final }, so this only works if you've got access to a custom
> API that allows you to fork the state so one branch goes to Final and the
> other continues with Update. It's good if you've got it, but a lot of
> implementations don’t.
Indeed, the hash required for EMS is usually the same as that required for
client authentication,
so implementations that support client auth already support this, others may
not.
>> Also, TLS 1.2 ServerKeyExchange signature is not taken over ClientHello and
>> ServerHello. This was famously exploited for FREAK and LOGJAM (and then there
>> is the DHE vs. ECDHE issue). Sadly, this was found out too late for changing
>> EMS extension to extend the signature.
>
> Hmm, what do people feel about adding this as a fix? Given that the attacks
> were based on implementations supporting crippled crypto when they shouldn't
> have and accepting an export cipher suite when they shouldn't have (i.e. they
> were pretty broken to begin with), is it worth the compatibility-breaking
> change to try and address this?
Adding the handshake hash to the ServerKeyExchange (a la EMS) provides
some nice protections against downgrade and seems to be worth the effort.
Of course, for all of these LTS improvements, we need to assume that the
LTS extension itself cannot be deleted by the attacker. That is, we’d assume
that the client or server supports *only* LTS mode. Otherwise, we’d have
to look closer to eliminate other downgrade attacks.
-Karthik
>
>> Then there is the problem that DHE parameter sizes are not negotiated. This
>> is severe enough problem that it renders DHE effecively unusable in some
>> contexts
>
> That's such a can of worms there that I don't really want to get into it in
> -LTS, unless lots of people really want to see it addressed...
>
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
