> On Oct 27, 2017, at 5:02 AM, Hanno Böck <ha...@hboeck.de> wrote:
>
>> Which is different from
>> requiring that clients or servers reject weaker options, but given
>> such a server requirement, it would not be too unreasonable for STS
>> clients to in fact require at least TLS 1.2 and its MIT ciphersuites
>> from STS servers.
>
> The MTI cipher in TLS 1.2 is
> TLS_RSA_WITH_AES_128_CBC_SHA
>
> Which doesn't support forward secrecy and is affected by two major
> cryptographic flaws (Vaudenay padding oracle and Bleichenbacher million
> message attack) that are hard to avoid in implementations.
>
> I don't want to discuss here how it happened that the TLS 1.2 authors
> decided to declare such a cipher as "MTI", but I think it would be
> actively harmful to require a cipher in any modern standard that I'd
> argue should be deprecated better sooner than later.
It is a lot stronger than *cleartext*, which what we're trying to
improve on with STS. Also chosen plaintext attacks that makes
these relevant in HTTP enabling retrieval of cookies, ... don't
carry over into SMTP. And negotiating EtM fixes the all these
deficits in TLS 1.2, resulting in a cipher that is likely more
secure the the fragile GCM.
Mostly we shoul major layer violations here. Servers will
support the vast majority of non-deprecated ciphers and need
to support at least the MTI ciphers. Clients will likely balk
at doing RC4 or 3DES, and insist on AES128. They'll likely
prefer ciphers with DHE or ECDHE and GCM (for better or worse)
over other types of ciphers, but STS should be over prescriptive
here. As my name appears on the DROWN paper, I would be remiss
of me to not concede that RSA key transport should be avoided,
but the way to do that is promote the use of stronger options
more than by proscribing the weaker ones. The basic TLS protocol
does a fair job of avoiding downgrade attacks, especially because
MTAs (unlike browsers) don't generally do the protocol fallback
dance.
The STS should not be more specific than perhaps requiring TLS 1.2
support with the MTI ciphers and DHE and ECDHE preferred over over
RSA key transport.
It would be unwise here to attempt to go toe to toe with the bleeding
edge security ratcheting being done in the browser space. SMTP will
lag some efforts as email server infrastructure has a longer field
lifetime than desktop browsers, and there's no one to click OK on
a per-message basis when interoperability fails. For opportunistic
security to be broadly deployed, it must just work, and so be a bit
more forgiving of superficial scratches.
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
