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

[Spencer Dawkins at IETF <[e-mail]>]

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 <[e-mail]> wrote:

> 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
> --
> Model-t mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/model-t
>