Merge branch 'master' of github.com:SystemsApproach/security

Author: llpeterson

authentication.rst

@@ -15,15 +15,16 @@ could be replayed, appearing to the website as though you had ordered
 more of the same. Even though it wasn’t the original incarnation of
 the message, its authentication code would still be valid; after all,
 the message was created by you, and it wasn’t modified. Clearly, we
-need a solution that ensures *originality*.
+need a solution that ensures *freshness*.
 
 In a variation of this attack called a *suppress-replay attack*, an
 adversary might merely delay your message (by intercepting and later
 replaying it), so that it is received at a time when it is no longer
 appropriate. For example, an adversary could delay your order to buy
 stock from an auspicious time to a time when you would not have wanted
-to buy. Although this message would in a sense be the original, it
-wouldn’t be timely. So we also need to ensure *timeliness*. Originality
+to buy. Although this message would in a sense be fresh (it hasn't
+been sent before), it
+wouldn’t be timely. So we also need to ensure *timeliness*. Freshness
 and timeliness may be considered aspects of integrity. Ensuring them
 will in most cases require a nontrivial, back-and-forth protocol.
 
@@ -32,7 +33,7 @@ key. A session key is a secret-key cipher key generated on the fly and
 used for just one session. This too involves a nontrivial protocol.
 
 What these two issues have in common is authentication. If a message is
-not original and timely, then from a practical standpoint we want to
+not fresh and timely, then from a practical standpoint we want to
 consider it as not being authentic, i.e., not being from whom it claims to be.
 And, obviously, when you are arranging to share a new session key with
 someone, you want to know you are sharing it with the right person.
@@ -47,15 +48,15 @@ Diffie-Hellman key exchange in its simplest form does not provide
 authentication, but in practical usage it is almost always combined
 with an authentication protocol.
 
-There is a core set of techniques used to ensure originality and
+There is a core set of techniques used to ensure freshness and
 timeliness in authentication protocols. We describe those techniques
 before moving on to particular protocols.
 
-5.1 Originality and Timeliness Techniques
+5.1 Freshness and Timeliness Techniques
 -------------------------------------------
 
 We have seen that authentication codes alone do not enable us to detect
-messages that are not original or timely. One approach is to include a
+messages that are not fresh or timely. One approach is to include a
 timestamp in the message. Obviously the timestamp itself must be
 tamperproof, so it must be covered by the message authentication code. The primary
 drawback to timestamps is that they require distributed clock

firewall.rst

@@ -154,7 +154,6 @@ described above with the following command:
 Then we can check that our rule was applied correctly:
 
 .. literalinclude:: code/fwsnip2
-                    
 
 In the preceding discussion, the firewall forwards everything except
 where specifically instructed to filter out certain kinds of packets. A
@@ -423,8 +422,8 @@ we recommend our companion book on software-defined networks.
 .. admonition:: Further Reading
 
    L. Peterson, C. Cascone, B. O’Connor, T. Vachuska,
-      and B. Davie. `Software-Defined Networks: A Systems
-      Approach <https://sdn.systemsapproach.org>`__.
+   and B. Davie. `Software-Defined Networks: A Systems
+   Approach <https://sdn.systemsapproach.org>`__.
 
 9.4 Zero Trust Security
 -------------------------
@@ -546,17 +545,13 @@ and authorization” although it's less memorable.
 .. admonition:: Further Reading
 
    S. Rose, O. Borchert, S. Mitchell, S. Connelly. `Zero Trust
-      Architecture
-      <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf>`__. NIST, 2020.
+   Architecture <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf>`__. NIST, 2020.
 
-   C. Cunningham. `A Look Back At Zero Trust: Never Trust, Always
-      Verify
-      <https://www.forrester.com/blogs/a-look-back-at-zero-trust-never-trust-always-verify/>`__. Forrester, 2020.
+   C. Cunningham. `A Look Back At Zero Trust: Never Trust, Always Verify
+   <https://www.forrester.com/blogs/a-look-back-at-zero-trust-never-trust-always-verify/>`__. Forrester, 2020.
 
    R. Ward and B. Beyer. `BeyondCorp: A New Approach to Enterprise
-      Security
-      <https://www.usenix.org/system/files/login/articles/login_dec14_02_ward.pdf>`__.
-      ;login:, Usenix, 2014.
+   Security <https://www.usenix.org/system/files/login/articles/login_dec14_02_ward.pdf>`__. ;login:, Usenix, 2014.
 
 9.5. Intrusion Detection and Prevention
 --------------------------------------------

infra.rst

@@ -108,13 +108,13 @@ more difficult to address.
 .. _reading_threat:
 .. admonition::  Further Reading
 
-   G. Huston. `A Survey on Securing Inter-Domain Routing Part 1 –
-   BGP: Design, Threats and Security Requirements
-   <https://labs.apnic.net/index.php/2021/08/03/a-survey-on-securing-inter-domain-routing-part-1-bgp-design-threats-and-security-requirements/>`__.
+   S. Murphy. `BGP Security Vulnerabilitiess
+   Analysis <https://www.rfc-editor.org/info/rfc4272>`__. RFC 4272, January 2006.
+ 
+   G. Huston. `A Survey on Securing Inter-Domain Routing Part 1. 
+   BGP: Design, Threats and Security Requirements <https://labs.apnic.net/index.php/2021/08/03/a-survey-on-securing-inter-domain-routing-part-1-bgp-design-threats-and-security-requirements/>`__.
    APNIC Blog, August 2021.
 
-   S. Murphy. `BGP Security Vulnerabilities Analysis <https://www.rfc-editor.org/info/rfc4272>`__. RFC 4272, 2006.
-
    L. Peterson and B. Davie. `Computer Networks: A Systems Approach. Interdomain
    Routing <https://book.systemsapproach.org/scaling/global.html#interdomain-routing-bgp>`__.
 
@@ -317,7 +317,7 @@ additional layers in this hierarchy. A hierarchy of
 certificates can be created to follow this hierarchy of address
 allocation.  The RIRs form trust anchors from which chains of trust
 can be built, much the way a modern browser comes with a set of
-trusted root certification authorities (CAs) so that the certificates
+trusted root certificate authorities (CAs) so that the certificates
 issued by web sites, which are signed by CAs, can be checked for validity.
 
 A key distinction between RPKI and the certificates that we are
@@ -519,7 +519,7 @@ or numbers corresponding to the AS in which the router is located.
 As with all public key certificates, we need a chain of trust from a
 trusted root to the router certificate. For example, an RIR could
 provide the root of trust, and sign certificates for ISPs, who
-could then act as the certification authorities for their own routers. The
+could then act as the certificate authorities for their own routers. The
 use of the word "could" in this paragraph reflects the lack of
 real-world deployment of BGPsec.
 
@@ -884,7 +884,7 @@ While there are obvious similarities to the chains of trust used for
 TLS, the notable difference here is that the chain of
 certificates that must be followed is precisely defined by the
 hierarchy of the DNS. Whereas a TLS certificate could be issued by a
-range of certification authorities, the certificates for any zone in
+range of certificate authorities, the certificates for any zone in
 DNSSEC must be issued by the parent zone. This has some advantages,
 such as limiting the opportunities for bad behavior by CAs that has
 occasionally occurred with TLS certificates. However, it also

intro.rst

@@ -158,7 +158,7 @@ weaknesses exploited by the Morris worm.
 
 The rise in popularity of the World Wide Web in the 1990s created the
 demand for security features at the transport layer to support
-applications such as e-commerce. This lead to the creation of *SSL
+applications such as e-commerce. This led to the creation of *SSL
 (secure sockets layer)* which was superseded by *TLS (transport layer
 security)*, both of which provided confidentiality and authentication
 at the transport layer. TLS is an important case study for network
@@ -255,8 +255,8 @@ applicable to system security.
 
 .. admonition:: Further Reading
 
-  B. Schneier. Beyond Fear: Thinking Sensibly About Security in an
-     Uncertain World. Copernicus Books, 2003.
+   B. Schneier. Beyond Fear: Thinking Sensibly About Security in an
+   Uncertain World. Copernicus Books, 2003.
 
 It is also important to recognize that threats and trust are two sides
 of the same coin. A threat is a potential failure scenario that you
@@ -397,8 +397,8 @@ challenge. Security is easiest when the answer is always "no".
 
 .. admonition:: Further Reading
 
-  J. Saltzer and F. Kaashoek. `Principles of Computer System Design: An
-     Introduction. Chapter 11
-     <https://ocw.mit.edu/courses/res-6-004-principles-of-computer-system-design-an-introduction-spring-2009/pages/online-textbook/>`__. Morgan
-     Kaufmann Publishers, 2009.
+   J. Saltzer and F. Kaashoek. `Principles of Computer System Design: An
+   Introduction. Chapter 11
+   <https://ocw.mit.edu/courses/res-6-004-principles-of-computer-system-design-an-introduction-spring-2009/pages/online-textbook/>`__. Morgan
+   Kaufmann Publishers, 2009.
 

key-distro.rst

@@ -98,14 +98,16 @@ perhaps directly from Alice—as long as they trust Bob and know his
 public key. You can see how starting from a very small number of keys
 (in this case, just Bob’s) you could build up a large set of trusted
 keys over time. Bob in this case is playing the role often referred to
-as a *certification authority* (CA), and much of today’s Internet
-security depends on CAs. VeriSign is one well-known commercial CA.
+as a *certificate authority* (CA), and much of today’s Internet
+security depends on CAs. There are many commercial and non-profit CAs
+in widespread use today. You may also see CA expanded as
+*certification authority*—the two expansions are equivalent.
 
 One thing to note about the above example is that we have to know two
 things about Bob. First, we need to know his public key so that we can
 verify that certain messages were originated by Bob. But we also have
 to know that Bob is trustworthy enough to make statements about the
-keys of others, which is where certification authorities (rather than
+keys of others, which is where certificate authorities (rather than
 random individuals) come into play.  We return to this topic below.
 
 One of the major standards for certificates is known as X.509. This
@@ -138,7 +140,7 @@ domains.
 There are different ways a PKI could formalize the notion of trust. We
 discuss the two main approaches.
 
-4.1.1 Certification Authorities
+4.1.1 Certificate Authorities
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In the first model, trust is binary; you either trust someone
@@ -152,10 +154,10 @@ In other words, all you need is a chain of certificates, all signed by
 entities you trust, as long as it leads back to an entity whose key you
 already know.
 
-A *certification authority* or *certificate authority* (CA) is an entity
+A *certificate authority* or *certification authority* (CA) is an entity
 claimed (by someone) to be trustworthy for verifying identities and
 issuing public key certificates. There are commercial CAs, governmental
-CAs, and even free CAs. To use a CA, you must know its own key. You can
+CAs, and non-profit CAs. To use a CA, you must know its own key. You can
 learn that CA’s key, however, if you can obtain a chain of CA-signed
 certificates that starts with a CA whose key you already know. Then you
 can believe any certificate signed by that new CA.
@@ -172,7 +174,7 @@ trust for that participant.
    :width: 600px
    :align: center
 
-   Tree-structured certification authority hierarchy.
+   Tree-structured certificate authority hierarchy.
 
 There are some significant issues with building chains of trust. Most
 importantly, even if you are certain that you have the public key of the
@@ -296,7 +298,7 @@ distribution of the CRL to prolong the amount of time they can use the
 compromised key. A number of proposals have been made to improve the
 effectiveness of certificate revocation, such as using bit vectors or
 other compact representations of the CRL to reduce its size, and the
-development of the Online Certification Status Protocol (OCSP) to
+development of the Online Certificate Status Protocol (OCSP) to
 enable real-time checks on a certificate's status. At the time of
 writing, there are some best practices for handling certificate
 revocation but no comprehensive solution. A good discussion of the
@@ -306,9 +308,9 @@ revocation can be found in the blog post below.
 .. admonition:: Further Reading
 
   J. Schank. `CRLite: Fast, private, and comprehensive certificate
-     revocation checking in Firefox
-     <https://hacks.mozilla.org/2025/08/crlite-fast-private-and-comprehensive-certificate-revocation-checking-in-firefox/>`__. Mozilla
-     blog, August 2025.
+  revocation checking in Firefox
+  <https://hacks.mozilla.org/2025/08/crlite-fast-private-and-comprehensive-certificate-revocation-checking-in-firefox/>`__. Mozilla
+  blog, August 2025.
 
 4.2 Distribution of Secret Keys
 ------------------------------------

principles.rst

@@ -56,7 +56,7 @@ whom we wish to communicate? Or how does a banking system know that
 the person behind a particular HTTP request is actually the account
 holder?
 
-Integrity also requires messages be *original* and *timely*, which is
+Integrity also requires messages be *fresh* and *timely*, which is
 threatened by the possibility data is captured and then retransmitted
 at some later time. This is known as a *replay attack*, where for
 example, we want to protect against an attacker repeatedly adding an

systems.rst

@@ -98,7 +98,7 @@ the need for any prior message exchange (and sidestepping some of the
 complexities described in the earlier chapter). Alice’s digital
 signature suffices to authenticate her. Although there is no proof
 that the message is timely, legitimate email isn’t guaranteed to be
-timely either. There is also no proof that the message is original,
+timely either. There is also no proof that the message is fresh,
 but Bob is an email user and probably a fault-tolerant human who can
 recover from duplicate emails (which, again, are not out of the
 question under normal operation anyway). Alice can be sure that only
@@ -292,7 +292,7 @@ three degrees of freedom. First, it is highly modular, allowing users
 (or more likely, system administrators) to select from a variety of
 cryptographic algorithms and specialized security protocols. Second,
 IPsec allows users to select from a large menu of security properties,
-including access control, integrity, authentication, originality, and
+including access control, integrity, authentication, freshness, and
 confidentiality. Third, IPsec can be used to protect narrow streams
 (e.g., packets belonging to a particular TCP connection being sent
 between a pair of hosts) or wide streams (e.g., all packets flowing
@@ -479,8 +479,8 @@ you to the paper.
 .. admonition:: Further Reading
 
    J. Donenfeld. `WireGuard: Next Generation Kernel Network Tunnel
-      <https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/WireGuard-next-generation-kernel-network-tunnel/>`__.
-      NDSS, 2017.
+   <https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/WireGuard-next-generation-kernel-network-tunnel/>`__.
+   NDSS, 2017.
 
 One of these types of tunnels plus a gateway or concentrator to
 terminate them is pretty much all that is needed to deliver a remote
@@ -646,7 +646,7 @@ networking, a topic we discuss in chapter 9.
 .. admonition:: Further Reading
 
    A. Pennarun. `How Tailscale Works <https://tailscale.com/blog/how-tailscale-works>`__.
-      Tailscale blog, 2020.
+   Tailscale blog, 2020.
 
 
 7.5 Web Authentication and Passkeys
@@ -957,7 +957,7 @@ a companion book.
 .. admonition:: Further Reading
 
    L. Peterson, O. Sunay, and B. Davie. `Private 5G: A Systems
-      Approach. <https://5g.systemsapproach.org>`__.
+   Approach. <https://5g.systemsapproach.org>`__.
 
 Assuming the AMF recognizes the IMSI, it initiates an authentication
 protocol with the device. There are a set of options for

tls.rst

@@ -146,7 +146,7 @@ between client and server will be encrypted. But we still have to rule
 out the MITM attack.
 
 3. The server now sends one or more certificates. In the simplest
-   case, there is a single certificate signed by a certification
+   case, there is a single certificate signed by a certificate
    authority (CA) that is trusted by the client.
 
 4. The server sends a "certificate verify" message, which proves that
@@ -318,10 +318,11 @@ the binding, and if the HMAC calculation succeeds, then the server and
 client now have agreement that they can use a shared secret
 established in the prior session. They use a "resumption master
 secret" that was calculated and stored in the prior session to derive
-a new set of keys for this session. The keys of the new
-session are different from those of the prior session to support
-forward secrecy (i.e., an attacker who learns the key for session N
-doesn't immediately have the keys for session N+1).
+a new set of keys for this session. The keys of the new session are
+different from those of the prior session to support forward secrecy
+(i.e., even if an attacker manages to compromise the key for one
+session, they don't gain the ability to decrypt data from other
+sessions).
 
 When the server sends its "Finished" message, it calculates the HMAC
 over the handshake messages using the agreed-upon new key, and thus
@@ -349,15 +350,15 @@ provided by the socket layer (b) the application must know how to deal
 with replays of data sent as 0-RTT, e.g., by only sending 0-RTT
 data for operations that are idempotent.
 
-The other drawback of 0-RTT data is that it depends on keys that are
+The other drawback of 0-RTT data is that it depends on tickets that are
 derived from secrets used in an earlier transaction. If those secrets
 were somehow compromised, the attacker would have the necessary
 information to compromise the new session. Thus, 0-RTT data lacks
 forward secrecy. For this reason, the option exists to generate a new
 set of keys as part of the session resumption handshake with a new
 Diffie-Hellman exchange. This means that only the data sent in the
 first RTT lacks forward secrecy, and the rest of the session is
-protected by the new, uncompromised keys.
+protected by the new ephemeral keys.
 
 
 All of this work to reduce the setup time of TLS by a single RTT might
@@ -528,7 +529,7 @@ need to consider how all the parts of a system interact with each
 other to form a coherent whole, rather than just looking at single
 components in isolation. For example, TLS is a system that includes
 both public-key and symmetric-key cryptography, authentication and
-privacy mechanisms, certification authorities, and sub-layers such as
+privacy mechanisms, certificate authorities, and sub-layers such as
 the record protocol and the handshake protocol. But the systems
 approach applies recursively too. As we have already seen, it is
 important to look at how TLS sits within the overall protocol stack,
@@ -552,7 +553,7 @@ another warning is presented. Users can generally choose to override
 these warnings but the overall effect is to reinforce behaviors that
 are more secure and discourage those that are insecure.
 
-Certification authorities are a critical part of this overall
+Certificate authorities are a critical part of this overall
 system. Most users have no way to determine whether any given CA does
 its job properly. As discussed in Chapter 4, the way that CA
 hierarchies work means that a lot of trust is placed at the top-level