Subject: [Uta] Establishing minimum TLS requirements for use with STS

From: Ivan Ristic <[email-masked]>
Date: Mon, 23 Oct 2017 22:09:45 +0100

At present, STS doesn't impose any restrictions on the quality of TLS
connection. Historically, new RFCs and protocols have been the only
opportunity to enforce better security. For comparison, HTTP/2 introduced a
requirement to use TLS 1.2 and suites with forward security and
authenticated encryption.

I think something similar should be done with MTA-STS. In particular,
forward security strikes me as extremely important, however the HTTP/2
approach seems sound overall.

-- 
Ivan

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 23 Oct 2017 14:23:35 -0700

Which all sounds like RFC 7525, the TLS BCP, that was published by this 
very working group.

Thanks,
	Yaron

On 23/10/17 14:09, Ivan Ristic wrote:
> opportunity to enforce better security. For comparison, HTTP/2 
> introduced a requirement to use TLS 1.2 and suites with forward security 
> and authenticated encryption.
> 
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Andrei Popov <[email-masked]>
Date: Mon, 23 Oct 2017 21:24:04 +0000

*   …however the HTTP/2 approach seems sound overall.
HTTP/2 RFC violates protocol layering by imposing restrictions on TLS parameters when the HTTP/2 ALPN ID is negotiated. When an HTTP/2 server is running on top of a general-purpose TLS stack, the TLS stack has to either implement HTTP/2-specific logic to restrict TLS parameters, or rely on the admin to provide compatible HTTP and TLS settings.

In practice, this has proved to be an extremely fragile arrangement: the admin does not expect HTTP/2 to stop working as a result of reordering/disabling certain TLS cipher suites. In my experience, a large number of customers who have run into this problem, solved it by disabling HTTP/2, rather than reordering TLS cipher suites.

Cheers,

Andrei

From: Uta [mailto:[email-masked]] On Behalf Of Ivan Ristic
Sent: Monday, October 23, 2017 2:10 PM
To: [email-masked]
Subject: [Uta] Establishing minimum TLS requirements for use with STS

At present, STS doesn't impose any restrictions on the quality of TLS connection. Historically, new RFCs and protocols have been the only opportunity to enforce better security. For comparison, HTTP/2 introduced a requirement to use TLS 1.2 and suites with forward security and authenticated encryption.

I think something similar should be done with MTA-STS. In particular, forward security strikes me as extremely important, however the HTTP/2 approach seems sound overall.

--
Ivan

---

From: Ivan Ristic <[email-masked]>
Date: Mon, 23 Oct 2017 22:51:27 +0100

What you're describing is a usability problem. For example, HTTP/2
specifies a mandatory-to-implement suite
(TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256);
if the software implementing HTTP/2 followed the RFC, everything would just
work. For example, they could refuse to run with invalid configuration,
forcing the issue. Or they could simply add the MIT suite to the end of the
configuration if not already there.

I don't think anyone likes crossing wires (and imposing TLS requirements
from elsewhere), but we do it because there's an upside. Every single
HTTP/2 connection uses TLS 1.2+ with AEAD and PFS. Back in the HTTP/1.x
world, TLS configuration is still a mess :)

On Mon, Oct 23, 2017 at 10:24 PM, Andrei Popov <[email-masked]>
wrote:

>
>    - …however the HTTP/2 approach seems sound overall.
>
> HTTP/2 RFC violates protocol layering by imposing restrictions on TLS
> parameters when the HTTP/2 ALPN ID is negotiated. When an HTTP/2 server is
> running on top of a general-purpose TLS stack, the TLS stack has to either
> implement HTTP/2-specific logic to restrict TLS parameters, or rely on the
> admin to provide compatible HTTP and TLS settings.
>
>
>
> In practice, this has proved to be an extremely fragile arrangement: the
> admin does not expect HTTP/2 to stop working as a result of
> reordering/disabling certain TLS cipher suites. In my experience, a large
> number of customers who have run into this problem, solved it by disabling
> HTTP/2, rather than reordering TLS cipher suites.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Uta [mailto:[email-masked]] *On Behalf Of *Ivan Ristic
> *Sent:* Monday, October 23, 2017 2:10 PM
> *To:* [email-masked]
> *Subject:* [Uta] Establishing minimum TLS requirements for use with STS
>
>
>

-- 
Ivan

---

From: Andrei Popov <[email-masked]>
Date: Mon, 23 Oct 2017 22:34:29 +0000

*   For example, HTTP/2 specifies a mandatory-to-implement suite (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); if the software implementing HTTP/2 followed the RFC, everything would just work. For example, they could refuse to run with invalid configuration, forcing the issue.
Whether connections start failing, or the application refuses to run using an updated application protocol, the end result is the same: the admin disables the updated protocol.

  *   Or they could simply add the MIT suite to the end of the configuration if not already there.
In many organizations, TLS configuration changes require approval, interop testing and performance testing. Whereas disabling the updated application protocol is quick and easy.

  *   Every single HTTP/2 connection uses TLS 1.2+ with AEAD and PFS.
Rather, a subset of AEAD/PFS TLS 1.2 connections also offer HTTP/2.

Cheers,

Andrei

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 24 Oct 2017 12:09:07 +0000

I think we talked about minimum TLS versions or acceptable cipher suites in
the past and concluded they were more reasonable as a hypothetical v2
feature.

I share the fear that this would be an impediment to adoption and lead to
people simply not using STS. Conversely, if we can get v1 out the door and
show meaningful usage and adoption, I think we have a far stronger case to
make that we should also define cipher suites.

On Mon, Oct 23, 2017 at 11:51 PM Ivan Ristic <[email-masked]> wrote:

> specifies a mandatory-to-implement suite (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256);
> On Mon, Oct 23, 2017 at 10:24 PM, Andrei Popov <[email-masked]
> > wrote:
>
>>

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 24 Oct 2017 15:44:00 +0300

> make that we should also define cipher suites.

I think the comparision of problems to HTTP/2 is very flawed:

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.

This is _not_ the case with HTTP/2. With HTTP/2, the client can _not_
drop unsatifactory ciphersuites unless it is prepared for fallback
handshake, which most clients are not. As consequence, the handshake
goes out with full cipher list, and depending on priority ordering, the
server can choose something that makes client puke.

And since this is fresh start, the servers can be required to support
reasonably modern things. And then the clients can require that or
not, depending on implementation. And I think RFC 7525 does not go far
enough[1]. 

[1] Some examples:

- No requirement to support AEAD, despite everything else being broken
  and support being widespread.
- No requirement to always support renegotiation_info, even if
  renegotiation is not supported.

-Ilari

---

From: Andrei Popov <[email-masked]>
Date: Tue, 24 Oct 2017 17:48:43 +0000

> In this case the client knows _beforehand_ that it has enhanced security requirements. 
This is the part I missed. In this case, limiting TLS parameters is just usual TLS profiling.

Thanks for clarifying,

Andrei

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 25 Oct 2017 15:29:20 +0000

OK. So to resolve this quickly, do we have proposed language? Is it just
https://tools.ietf.org/html/rfc7540#section-9.2 (i.e. use TLS1.2 or above,
blacklist these: https://tools.ietf.org/html/rfc7540#appendix-A)?

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 25 Oct 2017 20:06:30 +0300

>    renegotiation is not supported.

If you think RFC7525 is lacking, feel free to propose a -bis version. 
I'm not being snarky: things might have changed in the 2 1/2 years since 
the document was published (and 4 years since the first private draft), 
so it may be a good time for an upgrade.

OTOH, I think it would be silly to try to redo 7525 (and improve on it!) 
with a few paragraphs in this document, rather than simply referring to 
the BCP.

Thanks,
	Yaron

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 25 Oct 2017 20:29:21 +0300

On Wed, Oct 25, 2017 at 08:06:30PM +0300, Yaron Sheffer wrote:
> If you think RFC7525 is lacking, feel free to propose a -bis version. I'm
> not being snarky: things might have changed in the 2 1/2 years since the
> document was published (and 4 years since the first private draft), so it
> may be a good time for an upgrade.

I do not think revising RFC 7525 before publication of TLS 1.3 is a
good idea.

And even if TLS 1.3 has quite a bit of momentum already, it will take
some time for it to become widespread after the specification is
published. Reminds me of HTTP/2. That too had quite bit of momentum
and had quite a bit of deploymet quite quickly, but still has
not even close to displaced HTTP/1.1.

-Ilari

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 25 Oct 2017 14:16:06 -0400

> On Oct 24, 2017, at 8:44 AM, Ilari Liusvaara <[email-masked]> wrote:
> 

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.

---

From: Richard Moore <[email-masked]>
Date: Wed, 25 Oct 2017 22:27:00 +0100

>   willing to oblige the server.
​I'd say that the recipient domain is actually making a contract that it
guarantees to continue to provide the possibility of enhanced security.​ A
client that enforces STS will enforce that contract. By providing this
guarantee clients are able to enforce a stronger security assurance since
they know that the server will do its part. So I'd say your
characterisation has things backwards.

Regards

Rich.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 25 Oct 2017 17:50:50 -0400

> On Oct 25, 2017, at 5:27 PM, Richard Moore <[email-masked]> wrote:
> 
> ​I'd say that the recipient domain is actually making a contract that it guarantees to continue to provide the possibility of enhanced security.​ A client that enforces STS will enforce that contract. By providing this guarantee clients are able to enforce a stronger security assurance since they know that the server will do its part. So I'd say your characterisation has things backwards.

We can disagree on the mental model, but forwards or backwards,
the important thing to remember is that we're trying to raise
the ceiling and more often achieve more security, rather than
raise the floor and more often fail.

While some kind of floor is appropriate, it must not be bleeding
edge aggressive.  STS is still opportunistic security (with
authentication enabled when the appropriate signalling is seen
from the remote peer), and the considerations of RFC7435 still
apply.

-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Wed, 25 Oct 2017 15:13:59 -0700

A slightly different view of things, inline:

>   willing to oblige the server.

I wouldn't even characterize it as a request, but rather that the
recipient domain has a policy that it offers TLS to SMTP clients. It's
no more of a request than the STARTTLS response to EHLO is, it's just a
way of making that statement that is hopefully more resistant to
intermediaries, and includes information on the certificate that should
be presented in the negotiation. Even the "enforce" mode is only
advisory because it will be ignored by non-STS-implementing clients.

>   result of raising the ceiling (not the floor) applies here.

I see the "MUST NOT" here as being entirely outside the scope of STS. I
agree with you that being picky is likely to cause more breakage than
benefit, but deploying STS should not prohibit servers from being more
picky, perhaps for a server that is only accepting mail from a specific
community.

>   not be set unreasonably high.

Again, since STS is not specifying TLS parameters, so it should refrain
from telling the client what to do here.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 25 Oct 2017 18:57:05 -0400

> On Oct 25, 2017, at 6:13 PM, Jim Fenton <[email-masked]> wrote:
> 

I somewhat agree, and yet some guidance is appropriate, if only to enhance
interoperability so that server operators configure their servers to meet
the expected security floor, and clients have some idea about safe minima
they can enforce.

In RFC7435 I wrote:

   With unauthenticated, encrypted communication, OS protocols may
   employ more liberal settings than would be best practice when
   security is mandated by policy.  Some legacy systems support
   encryption, but implement only outdated algorithms or protocol
   versions.  Compatibility with these systems avoids the need to resort
   to cleartext fallback.

   For greater assurance of channel security, an OS protocol may enforce
   more stringent cryptographic parameters when the session is
   authenticated.  For example, the set of enabled Transport Layer
   Security (TLS) [RFC5246] cipher suites might exclude deprecated
   algorithms that would be tolerated with unauthenticated, encrypted
   communication.

   OS protocols should produce authenticated, encrypted communication
   when authentication of the peer is "expected".  Here, "expected"
   means a determination via a downgrade-resistant method that
   authentication of that peer is expected to work.  Downgrade-resistant
   methods include: validated DANE DNS records, existing TOFU identity
   information, and manual configuration.  Such use of authentication is
   "opportunistic", in that it is performed when possible, on a per-
   session basis.

The middle paragraph leaves room for setting a somewhat higher floor
for authenticated channels, and it would not be entirely inappropriate
for STS to provide some guidance to server operations of the required
minimum security.  Thus perhaps servers must support at least TLS 1.2,
and at least the associated MTI ciphersuites.  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.

-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Wed, 25 Oct 2017 16:02:40 -0700

> to in fact require at least TLS 1.2 and its MIT ciphersuites from STS

This is all good guidance, and it's all advisory (and in an
informational RFC, as well). What I was concerned about was the MUST NOT
you had included in your previous message.

---

From: Hanno Böck <[email-masked]>
Date: Fri, 27 Oct 2017 11:02:53 +0200

On Wed, 25 Oct 2017 18:57:05 -0400
Viktor Dukhovni <[email-masked]> 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.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: [email-masked]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 27 Oct 2017 05:20:40 -0400

> On Oct 27, 2017, at 5:02 AM, Hanno Böck <[email-masked]> wrote:
> 
>> Which is different from

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.

---

From: Hanno Böck <[email-masked]>
Date: Sat, 28 Oct 2017 22:32:38 +0200

On Fri, 27 Oct 2017 05:20:40 -0400

> MTAs (unlike browsers) don't generally do the protocol fallback

That's not how Bleichenbacher attacks work... (which you should know as
a co-author of the drown paper.) As it has been pointed out multiple
times this attack works cross-protocol and cross-server, so the mere
existence of a vulnerable TLS RSA implementaiton with the same cert is
a risk. You don't need any downgrade attack for that.

-- 
Hanno Böck
https://hboeck.de/

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 28 Oct 2017 19:05:05 -0400

> On Oct 28, 2017, at 4:32 PM, Hanno Böck <[email-masked]> wrote:
> 
> a co-author of the drown paper.)

You can safely drop the word "should"...

> As it has been pointed out multiple

Yes, in the DROWN case the attack was a cross-protocol attack that
leveraged servers that exposed a certificate used with SSLv3+ (on
the same or some other server) via SSLv2.

With SSLv2 out of the picture, which attacks from RFC7457 do see
as the motivation to set a floor higher than the TLS 1.2 MTI cipher
[ TLS_RSA_WITH_AES_128_CBC_SHA ] in SMTP?  Sure, clients and servers
will typically negotiate other ciphers (PFS and AESGCM are quite
common, and perhaps more secure, barring GCM pitfalls and ECDHE
being broken by quantum computers any day now...).

-- 
	Viktor.