Subject: [Model-t] Considerations for modern COMSEC protocol design

From: Eric Rescorla <[email-masked]>
Date: Mon, 17 Feb 2020 09:06:54 -0800

As promised...

-Ekr and Chris

RFC 3552 provides a description of classic issues for the development
of communications security protocols. However, in the nearly 20 years
since the publication of 3552, the practice of protocol design has
moved on to a fair extent. This note sketches some of the
considerations that should be considered when designing a communications
security protocol that are not covered in detail in 3552.

LIMIING TIME SCOPE OF COMPROMISE
RFC 3552; Section 3 says:

   The Internet environment has a fairly well understood threat model.
   In general, we assume that the end-systems engaging in a protocol
   exchange have not themselves been compromised.  Protecting against an
   attack when one of the end-systems has been compromised is
   extraordinarily difficult.  It is, however, possible to design
   protocols which minimize the extent of the damage done under these
   circumstances.

Although this text is technically correct, modern protocol designs
such as TLS 1.3 and MLS often try to provide a fair amount of defense
against various kinds of temporary compromise. Specifically:

- Forward Security: Many protocols are designed so that compromise of
  an endpoint at time T does not lead to compromise of data transmitted
  prior to some time T' < T. For instance, if a protocol is based on
  Diffie-Hellman key establishment, then compromise of the long-term
  keys does not lead to compromise of traffic sent prior to compromise
  if the DH ephemerals and traffic keys have been deleted.

- Post-Compromise Security: Conversely, if an endpoint is compromised
  at time T, it is often desirable to have the protocol "self-heal"
  so that a purely passive adversary cannot access traffic after
  a certain time T' > T. MLS, for instance, is designed with this
  property.

- Containing Partial Authentication Key Compromise: If an endpoint is
  stolen and its authentication secret is stolen, then an attacker can
  impersonate that endpoint. However, there a number of scenarios in
  which an attacker can obtain use of an authentication key but not
  the secret itself (see, for instance [0]). It is often desirable to
  limit the impact of such compromises (for instance, by avoiding
  unlimited delegation from such keys).

- Short-lived keys: Typical TLS certificates last for months or years.
  There is a trend towards shorter certificate lifetimes so as to minimize
  risk of exposure in the event of key compromise. Relatedly, delegated
  credentials are short-lived keys the certificate’s owner has delegated
  for use in TLS. These help reduce private key lifetimes without
compromising
  or sacrificing reliability.

FORCING ACTIVE ATTACK
RFC 3552; Section 3.2 notes that it is important to consider passive
attacks. In general, it is much harder to mount an active attack, both
in terms of the capabilities required and the chance of being
detected. Another theme in recent IETF protocols design is to build
systems which might have limited defense against active attackers but
are strong against passive attackers, thus forcing the attacker to go
active. Examples include DTLS-SRTP and the trend towards opportunistic
security. However, ideally protocols are built with strong defenses
against active attackers. One prominent example is QUIC, which takes
steps to ensure that off-path connection resets are intractable in
practice.

TRAFFIC ANALYSIS
RFC 3552; Section 3.2.1 describes how the absence of TLS or other
transport-layer encryption may lead to obvious confidentiality
violations against passive attackers. However, recent trends in
traffic analysis indicate encryption alone may be insufficient
protection for some types of application data [1]. Encrypted traffic
metadata, especially message size, can leak information about the
underlying plaintext. DNS queries and responses are particularly
at risk given their size distributions. Recent protocols account
for this leakage by supporting padding, either generically in the
transport protocol (QUIC and TLS), or specifically in the application
protocol (EDNS(0) padding option for DNS messages).

CONTAINING COMPROMISE OF TRUST POINTS
Many protocols are designed to depend on trusted third parties (the
WebPKI is perhaps the canonical example); if those trust points
misbehave, the security of the protocol can be completely compromised.

A number of recent protocols have attempted to reduce the power of
those trust points. For instance. Certificate Transparency attempts to
ensure that a CA cannot issue valid certificates without publishing
them, allowing third parties to detect certain classes of misbehavior
by those CA. Similarly, Key Transparency attempts to ensure that (public)
keys associated with a given entity are publicly visible and auditable
in tamper-proof logs. This allows users of these keys to check
them for correctness.

In the realm of software, Reproducible Builds and Binary
Transparency are intended to allow a user to determine that they
have received a valid copy of the binary that matches the auditable
source code. Blockchain protocols such as Bitcoin and Ethereum also
employ this principle of transparency and are intended to detect
misbehavior by members of the network.

[0] Jager, T., Schwenk, J., and J. Somorovsky, "On the Security of TLS
1.3 and QUIC Against Weaknesses in PKCS#1 v1.5 Encryption",
Proceedings of ACM CCS 2015, DOI 10.1145/2810103.2813657, October
2015, <https://www.nds.rub.de/media/nds/
veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf>.
[1] https://tools.ietf.org/html/draft-wood-pearg-website-fingerprinting-00

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 17 Feb 2020 11:57:14 -0600

I'm not an active participant here, and the Internet is likely better for
that, but this is exactly the kind of conversation I was hoping Model-T
would be having.

Eric, thanks for sending this.

Spencer

On Mon, Feb 17, 2020 at 11:07 AM Eric Rescorla <[email-masked]> wrote:

> [0] Jager, T.., Schwenk, J., and J. Somorovsky, "On the Security of TLS
> --
> Model-t mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/model-t
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Feb 2020 20:47:01 +0000

Hiya,

Thanks for the great text. That really ought land in some
I-D or RFC sometime. (I'd probably like to use that with
permission in our I-D if that'd be ok.)

While I agree with all your text, there's maybe a little
more to say on this bit...

> steps to ensure that off-path connection resets are intractable in

I'm still a fan of opportunistic security (OS) as
described in RFC7435, but in the time since that was
written, I think I've slightly modified my position on
the topic. Nowadays, I think OS is most useful when
it's a practical step on a realistic path from OS to
defense against active attackers, e.g. the evolution
from where we were in 2014 to MTA-STS (RFC8461) is
maybe a good example. I won't try wordsmith that in,
but be interested if you/others think similarly.

Cheers,
S.

---

From: Jim Fenton <[email-masked]>
Date: Mon, 17 Feb 2020 13:15:20 -0800

> but be interested if you/others think similarly.

I'm somewhat less of a fan of opportunistic security; before deciding
that the capabilities required for an active attack are harder to mount,
you need to consider the threat model. Consider that there are several
countries that have been launching downgrade attacks against SMTP
STARTTLS on a substantial fraction of their outgoing traffic [1]. And
that doesn't even consider more targeted attacks against specific clients.

[1] Durumeric, Zakir, David Adrian, Ariana Mirian, James Kasten, Elie
Bursztein, Nicolas Lidzborski, Kurt Thomas, Vijay Eranti, Michael
Bailey, and J. Alex Halderman. 2015. “Neither Snow Nor Rain Nor MITM...:
An Empirical Analysis of Email Delivery Security.” In /Proceedings of
the 2015 Internet Measurement Conference/, 27–39. IMC ’15. Tokyo, Japan:
Association for Computing Machinery.
https://doi.org/10.1145/2815675.2815695.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Feb 2020 21:23:20 +0000

Hiya,

On 17/02/2020 21:15, Jim Fenton wrote:
> I'm somewhat less of a fan of opportunistic security; 

Yeah, I think it's fair to say that very reasonable people
do have differing opinions about OS. (That might mean that
Ekr and Chris were wise to say less about it than unwise me
would naturally emit:-)

> before deciding

Sure, [1] is a fine paper and yes such attacks have been
mounted.

However, I don't think there was ever a point in time when
it'd have been possible to seriously argue that *everyone*
MUST turn on TLS authentication in STARTTLS - that just
isn't going to happen all at once at all MTAs. Whereas,
it was entirely possible to encourage everyone to at least
turn on TLS, and enough people have now done that that I
think MTA-STS is now quite credible. (Noting that MTA-STS
comes with the testing and reporting stuff which I'd argue
is also maybe needed in that case.)

Cheers,
S.

---

From: Joachim Fabini <[email-masked]>
Date: Tue, 18 Feb 2020 12:39:27 +0100

thanks EKR for the concise summary. Some minor
additions/comments/thoughts on the traffic analysis paragraph and on e2e
aspects below.

On 2/17/20 6:06 PM, Eric Rescorla wrote:
> [...]
> metadata, especially message size, 

In addition, message timing, -sequence, -patterns are the features most
useful and commonly available whenever attacking encrypted (and
potentially aggregated) protocol traffic. Worth mentioning...

> can leak information about the

Time synchronization protocols can be mentioned here as a use case, too.
Currently none of the existing TS protocols is adequately protected
against timing attacks (assumptions concerning link diversity typically
fail whenever the attacker is well-positioned, e.g., on the majority of
the system's few access links). And timing becomes crucial for many systems.

Moreover, the accuracy of (today's) network-based timesync depends on
deterministic message patterns, sizes and timing. Consequently (a) any
attempt to secure/obscure these messages impairs on timesync accuracy
and (b) timesync messages can be spotted easily within encrypted traffic
(even including IPsec-tunneled timesync, despite TFC and obscuring
traffic - references on request).

At least a note could be added that subliminal channels do exist and
should be considered when designing (security) protocols. I'll try to go
into more detail with the malware draft.

Finally, somebody mentioned during Friday's telco that "we don't know
who provides security". Imo this is where the threat landscape changed
most since 2003. RFC3552 does not even include the definition of an
endpoint (imo because by the time of writing it was too obvious what's
meant). Security frameworks, containers, virtual guests, clouds, etc.,
changed the rules of the game. They help but their transparency can be
painful in a security context.

So it boils down to a (again, imo) central question that the CLESS
endpoint taxonomy draft tackles to a certain extent: "what does
end-to-end mean"?

Is it meaningful/mandatory that future protocol/framework security
specifications are forced to make explicit what their perception or
concept of end-to-end is? Rewording this slightly: Users and
applications should have a right to identify/query which underlying
layers provide (e2e) security, i.e., where e2e security really ends.
And, in addition, which layers/frameworks/etc. (either local or remote)
sit in between and could break end-to-end security without being noticed.

br Joachim

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Feb 2020 06:27:35 -0800

> potentially aggregated) protocol traffic. Worth mentioning...

Yes, I agree with this.

> into more detail with the malware draft.

Hmm.... What do you think protocol designers would do with this information?
Every modern comsec protocol I am familiar with has zillions of bits that
can
be freely chosen, and though there's been a bunch of work on deransomization
I don't think we're ready to change that.

> sit in between and could break end-to-end security without being noticed.

This seems like a kind of normative statement that 3552 generally strove to
avoid, and I think should remain out of scope here. I think it would be a
good
idea to explain that the endpoint you are talking to now is probably really
distributed, but I don't think we should be taking a position on the users
rights vis-a-vis that.

-Ekr

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 18 Feb 2020 07:27:05 -0800

On Tue, Feb 18, 2020, at 6:27 AM, Eric Rescorla wrote:
> 
> 
> On Tue, Feb 18, 2020 at 3:39 AM Joachim Fabini 
> <[email-masked]> wrote:

+1, though let's not get carried away. (The list can grow to thousands of features.)

> Every modern comsec protocol I am familiar with has zillions of bits that can
> avoid, and I think should remain out of scope here. I think it would be a good

---

From: Joachim Fabini <[email-masked]>
Date: Tue, 18 Feb 2020 16:40:34 +0100

On 2/18/20 3:27 PM, Eric Rescorla wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
> 

I suppose your question concerns just the last sentence?

The former statements on time synchronization should warn protocol
designers that they must not rely on the timing of messages and that
encryption/security does not help in this respect, either.
In Industry and in the academic community it is a common misbelief that
encryption helps against timing attacks (can reference several
publications relying on such assumptions). People are not aware of this
pitfall and it is fair to warn.

> I don't think we're ready to change that.

Still: the less degrees of freedom protocol designers provide in their
freely selectable bits, the better. My concern is not so much about
end-to-end subliminal channels, but about the zillions intermediate
layers between pretended "end-to-end" and the actual security layer below.

> distributed, but I don't think we should be taking a position on the users

No need to involve users. The advise to protocol designers could be as
simple as: minimize the number of layers between the application that
needs end-to-end security and the actual {encryption/integrity
protection} layer. The fewer uncertainty factors there are in between,
the better.

>From a purely academic perspective I'd love to have a traceroute-kind
mechanism that allows users/applications to trace e2e all layers,
modules, frameworks involved in an e2e communication. But I guess this
truly exceeds the scope of model-t. ;)

thanks,
Joachim