Internet DRAFT - draft-arkko-farrell-arch-model-t-3552-additions

draft-arkko-farrell-arch-model-t-3552-additions







Network Working Group                                           J. Arkko
Internet-Draft                                                  Ericsson
Intended status: Informational                                S. Farrell
Expires: August 26, 2021                          Trinity College Dublin
                                                       February 22, 2021


        RFC 3552 additions due to evolving Internet thread model
           draft-arkko-farrell-arch-model-t-3552-additions-01

Abstract

   Communications security has been at the center of many security
   improvements in the Internet.  The goal has been to ensure that
   communications are protected against outside observers and attackers.

   This memo suggests additions to the RFC 3552 threat model to cater
   for the evolving security and privacy issues seen on the Internet
   today.  For instance, it is often also necessary to protect against
   endpoints that are compromised, malicious, or whose interests simply
   do not align with the interests of users.  While such protection is
   difficult, there are some measures that can be taken and we argue
   that investigation of these issues is warranted.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 26, 2021.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Arkko & Farrell          Expires August 26, 2021                [Page 1]

Internet-Draft             RFC 3552 additions              February 2021


   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The range of potential changes in BCP 72/RFC 3552 . . . . . .   3
   3.  Simple change . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Change to add discussion of compromises . . . . . . . . . . .   4
   5.  Change to add guidance with regards to communications
       security  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Limiting time scope of compromise . . . . . . . . . . . .   5
     5.2.  Forcing active attack . . . . . . . . . . . . . . . . . .   6
     5.3.  Traffic analysis  . . . . . . . . . . . . . . . . . . . .   6
     5.4.  Containing compromise of trust points . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Appendix A.  Contributors . . . . . . . . . . . . . . . . . . . .   9
   Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Communications security has been at the center of many security
   improvements in the Internet.  The goal has been to ensure that
   communications are protected against outside observers and attackers.
   At the IETF, this approach has been formalized in BCP 72 [RFC3552],
   which defined the Internet threat model in 2003.

   The purpose of a threat model is to outline what threats exist in
   order to assist the protocol designer.  But RFC 3552 also ruled some
   threats to be in scope and of primary interest, and some threats out
   of scope [RFC3552]:

      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,




Arkko & Farrell          Expires August 26, 2021                [Page 2]

Internet-Draft             RFC 3552 additions              February 2021


      possible to design protocols which minimize the extent of the
      damage done under these circumstances.

      By contrast, we assume that the attacker has nearly complete
      control of the communications channel over which the end-systems
      communicate.  This means that the attacker can read any PDU
      (Protocol Data Unit) on the network and undetectably remove,
      change, or inject forged packets onto the wire.

   However, the communications-security -only threat model may not
   entirely match today's reality, as discussed in
   [I-D.arkko-farrell-arch-model-t-redux].

   The rest of this document tentatively suggests some changes to the
   BCP.  Section 2 discussses the range of potential changes, and
   Section 3, Section 4, and Section 5 present the suggested alternative
   changes, in increasing amount of detail.

   Comments are solicited on this document.  The best place for
   discussion is on the model-t list.
   (https://www.ietf.org/mailman/listinfo/model-t)

2.  The range of potential changes in BCP 72/RFC 3552

   BCP 72/RFC 3553 [RFC3552] defines an "Internet Threat Model" and
   provides guidance on writing Security Considerations sections in
   other RFCs.

   [RFC3552] also provided a description of classic issues for the
   development of communications security protocols.  However, in the
   nearly 20 years since the publication of RFC 3552, the practice of
   protocol design has moved on to a fair extent.

   It is important to note that BCP 72 is (or should be:-) used by all
   IETF participants when developing protocols.  Potential changes to
   RFC 3552 therefore need to be brief - IETF participants cannot in
   general be expected to devote huge amounts of time to developing
   their security considerations text.  Potential changes also need to
   be easily understood as IETF participants from all backgrounds need
   to be able to use BCP 72.

   In this section we provide a few initial suggested changes to BCP 72
   that will need to be further developed as part of this work.

   There are a range of possible updates.  We could propose adding a
   simple observation (Section 3), or additionally propose further
   discussion about endpoint compromises and the need for system-level
   security analysis (Section 4).



Arkko & Farrell          Expires August 26, 2021                [Page 3]

Internet-Draft             RFC 3552 additions              February 2021


   Another possibility would be to add more guidance covering areas of
   concern, and recommendations of broadly-applicable techniques to use.
   One suggestion (due to others) for such material is provided in
   Section 5.

   The authors of this memo believe that any updates to RFC 3552 should
   be relatively high-level and short.  Additional documents may be
   needed to provide further detail.

3.  Simple change

   This is the simple addition we are suggesting.  As evidenced in the
   OAuth quote in [I-D.arkko-farrell-arch-model-t] Section 4 - it can be
   useful to consider the effect of compromised endpoints on those that
   are not compromised.  It may therefore be interesting to consider the
   consequences that would follow from a change to [RFC3552] that
   recognises how the landscape has changed since 2003.

   One initial, draft proposal for such a change could be:

   OLD:

      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.

   NEW:

      In general, we assume that the end-system engaging in a protocol
      exchange has not itself been compromised.  Protecting against an
      attack of a protocol implementation itself is extraordinarily
      difficult.  It is, however, possible to design protocols which
      minimize the extent of the damage done when the other parties in a
      protocol become compromised or do not act in the best interests
      the end-system implementing a protocol.

4.  Change to add discussion of compromises

   The following new section could be added to discuss the capabilities
   required to mount an attack:

   NEW:

   3.x.  Other endpoint compromise




Arkko & Farrell          Expires August 26, 2021                [Page 4]

Internet-Draft             RFC 3552 additions              February 2021


      In this attack, the other endpoints in the protocol become
      compromised.  As a result, they can, for instance, misuse any
      information that the end-system implementing a protocol has sent
      to the compromised endpoint.

   System and architecture aspects definitely also need more attention
   from Internet technology developers and standards organizations.
   Here is one possible addition:

   NEW:

      The design of any Internet technology should start from an
      understanding of the participants in a system, their roles, and
      the extent to which they should have access to information and
      ability to control other participants.

5.  Change to add guidance with regards to communications security

   Finally, the following new text could be added to cover some of the
   aspects that should be considered when designing a communications
   security protocol that are not covered in detail in RFC 3552.

5.1.  Limiting time scope of compromise

   [RFC3552] 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:

   NEW:

      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.




Arkko & Farrell          Expires August 26, 2021                [Page 5]

Internet-Draft             RFC 3552 additions              February 2021


      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
      [Jager2015]).  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.

5.2.  Forcing active attack

   [RFC3552] Section 3.2 notes that it is important to consider passive
   attacks.  This is still valid, but needs further elaboration:

   NEW:

      In general, it is much harder to mount an active attack, both in
      terms of the capabilities required and the chance of being
      detected.  A 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.

5.3.  Traffic analysis

   [RFC3552] Section 3.2.1 describes how the absence of TLS or other
   transport-layer encryption may lead to obvious confidentiality




Arkko & Farrell          Expires August 26, 2021                [Page 6]

Internet-Draft             RFC 3552 additions              February 2021


   violations against passive attackers.  This too is still valid, but
   does not take into account additional aspects:

   NEW:

      However, recent trends in traffic analysis indicate encryption
      alone may be insufficient protection for some types of application
      data [I-D.wood-pearg-website-fingerprinting].  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.

   Some examples of recent work in this area include support for padding
   either generically in the transport protocol (QUIC
   [I-D.ietf-quic-transport] and TLS [RFC8446]), or specifically in the
   application protocol (EDNS(0) padding option for DNS messages
   [RFC7830]).

5.4.  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.

   Some additional guidance in RFC 3552 might be needed to remind
   protocol readers of this.

   NEW:

      A number of recent protocols have attempted to reduce the power of
      trust points that the protocol or application depends on.  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.




Arkko & Farrell          Expires August 26, 2021                [Page 7]

Internet-Draft             RFC 3552 additions              February 2021


6.  Security Considerations

   The entire memo covers the security considerations.

7.  IANA Considerations

   There are no IANA considerations in this work.

8.  References

8.1.  Normative References

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,
              <https://www.rfc-editor.org/info/rfc3552>.

8.2.  Informative References

   [I-D.arkko-farrell-arch-model-t]
              Arkko, J. and S. Farrell, "Challenges and Changes in the
              Internet Threat Model", draft-arkko-farrell-arch-model-
              t-04 (work in progress), July 2020.

   [I-D.arkko-farrell-arch-model-t-redux]
              Arkko, J. and S. Farrell, "Internet Threat Model
              Evolution: Background and Principles", draft-arkko-
              farrell-arch-model-t-redux-00 (work in progress), November
              2020.

   [I-D.ietf-quic-transport]
              Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", draft-ietf-quic-transport-34 (work
              in progress), January 2021.

   [I-D.wood-pearg-website-fingerprinting]
              Goldberg, I., Wang, T., and C. Wood, "Network-Based
              Website Fingerprinting", draft-wood-pearg-website-
              fingerprinting-00 (work in progress), November 2019.

   [Jager2015]
              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, https://www.nds.rub.de/media/nds/
              veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf ,
              October 2015.




Arkko & Farrell          Expires August 26, 2021                [Page 8]

Internet-Draft             RFC 3552 additions              February 2021


   [RFC7830]  Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
              DOI 10.17487/RFC7830, May 2016,
              <https://www.rfc-editor.org/info/rfc7830>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

Appendix A.  Contributors

   Eric Rescorla and Chris Wood provided much of the text in Section 5.

Appendix B.  Acknowledgements

   The authors would like to thank the IAB:

   Alissa Cooper, Wes Hardaker, Ted Hardie, Christian Huitema, Zhenbin
   Li, Erik Nordmark, Mark Nottingham, Melinda Shore, Jeff Tantsura,
   Martin Thomson, Brian Trammel, Mirja Kuhlewind, and Colin Perkins.

   The authors would also like to thank the participants of the IETF
   SAAG meeting where this topic was discussed:

   Harald Alvestrand, Roman Danyliw, Daniel Kahn Gilmore, Wes Hardaker,
   Bret Jordan, Ben Kaduk, Dominique Lazanski, Eliot Lear, Lawrence
   Lundblade, Kathleen Moriarty, Kirsty Paine, Eric Rescorla, Ali
   Rezaki, Mohit Sethi, Ben Schwartz, Dave Thaler, Paul Turner, David
   Waltemire, and Jeffrey Yaskin.

   The authors would also like to thank the participants of the IAB 2019
   DEDR workshop:

   Tuomas Aura, Vittorio Bertola, Carsten Bormann, Stephane Bortzmeyer,
   Alissa Cooper, Hannu Flinck, Carl Gahnberg, Phillip Hallam-Baker, Ted
   Hardie, Paul Hoffman, Christian Huitema, Geoff Huston, Konstantinos
   Komaitis, Mirja Kuhlewind, Dirk Kutscher, Zhenbin Li, Julien
   Maisonneuve, John Mattson, Moritz Muller, Joerg Ott, Lucas Pardue,
   Jim Reid, Jan-Frederik Rieckers, Mohit Sethi, Melinda Shore, Jonne
   Soininen, Andrew Sullivan, and Brian Trammell.

   The authors would also like to thank the participants of the November
   2016 meeting at the IETF:

   Carsten Bormann, Randy Bush, Tommy C, Roman Danyliw, Ted Hardie,
   Christian Huitema, Ben Kaduk, Dirk Kutscher, Dominique Lazanski, Eric
   Rescorla, Ali Rezaki, Mohit Sethi, Melinda Shore, Martin Thomson, and
   Robin Wilton




Arkko & Farrell          Expires August 26, 2021                [Page 9]

Internet-Draft             RFC 3552 additions              February 2021


   Finally, the authors would like to thank numerous other people for
   insightful comments and discussions in this space.

Authors' Addresses

   Jari Arkko
   Ericsson
   Valitie 1B
   Kauniainen
   Finland

   Email: jari.arkko@piuha.net


   Stephen Farrell
   Trinity College Dublin
   College Green
   Dublin
   Ireland

   Email: stephen.farrell@cs.tcd.ie






























Arkko & Farrell          Expires August 26, 2021               [Page 10]