[Model-t] Considerations for modern COMSEC protocol design

[Eric Rescorla <[e-mail]>]

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