> On Oct 24, 2017, at 8:44 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
>
> In this case the client knows _beforehand_ that it has enhanced
> security requirements. Thus it can just drop ciphersuites that don't
> meet its requirements. This succeeds with any server that supports
> adequate security at all, regardless of priority ordering.
We're losing track of a few facts here:
- It is not the client that has enhanced security requirements,
rather it is the recipient domain that is politely requesting
enhanced security, and the client that supports STS is typically
willing to oblige the server.
- The baseline security is unauthenticated opportunistic TLS, so
anything better than that is progress. If we raise the bar too
high and mail delivery becomes fragile, STS will be disabled by
the users, they won't spend too much time fine-tuning TLS
parameters.
- Servers that support TLS will still continue to support normal
or DANE opportunistic TLS from clients that don't implement STS.
And the server has no way to know which type of client is doing
the handshake.
THEREFORE:
* Servers MUST NOT be picky about the minimum TLS parameters
they support. They MUST support a broad range of protocol
versions, ciphers, ... that are still used by a sufficient
fraction of fielded clients. This may change over time,
but bleeding edge security floors are NOT for SMTP. The
advice in RFC7435 about security gains being primarily a
result of raising the ceiling (not the floor) applies here.
* Clients SHOULD avoid deprecated and weak parameters that
be needed for interoperability of unauthenticated TLS with
non-STS/non-DANE servers when the server signals better
TLS support via DANE TLSA records and/or STS. We should
specify a minimum floor that servers are expected to meet
so that clients don't overshoot the server's capabilities.
Given that this is SMTP and the alternatives are no
authentication at all or even cleartext, the bar should
not be set unreasonably high.
In this protocol the client is doing the server a favour
by avoiding transmission in the clear at the server's
request. It is more important to succeed, than to exclude
the most sophisticated targeted attacks.
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
