Apply suggestions from kevin

Co-authored-by: knmeynell <[email protected]>

draft-dekater-scion-pki.md

@@ -1351,16 +1351,16 @@ This section describes the possible security risks and attacks that SCION's cont
 
 ## Kill Switches
 
-In a public key infrastructure, the certificate authorities have both the responsibility and power to issue and revoke certificates. If a CA is compromised or malicious, this power can unavoidably be abused. A misbehaving CA can plainly refuse to issue certificates to legitimate entities, or even issue illegitimate certificates to allow impersonating another entity. In the context of the SCION control plane PKI, refusing an AS to obtain or renew their AS certificate will ultimately cut the AS off from the network, turning the CP-PKI into a network "kill switch".
+In a public key infrastructure, the certificate authorities have both the responsibility and power to issue and revoke certificates. If a CA is compromised or malicious, this power can be abused. A misbehaving CA could refuse to issue certificates to legitimate entities, or even issue illegitimate certificates to allow impersonation of another entity. In the context of the SCION control plane PKI, refusing to issue or renew a certificate to an AS will ultimately cut that AS off from the network, turning the CP-PKI into a network "kill switch".
 
-SCION’s trust architecture fundamentally differs from a global monopolistic trust model. In SCION, each ISD manages its own trust roots instead of a single global entity providing those roots. This structure gives each ISD autonomy in terms of key management and in terms of trust. This prevents SCION from the occurrence of a global kill switch affecting all ISDs at once. However, local ISD kill switches are still possible in SCION. The following sections explain these cases and possible countermeasures.
+SCION’s trust architecture fundamentally differs from a global monopolistic trust model. In SCION, each ISD manages its own trust roots instead of a single global entity providing those roots. This structure gives each ISD autonomy in terms of key management and in terms of trust, and prevents the occurrence of a global kill switch affecting all ISDs at once. However, local ISD kill switches are still possible in SCION. The following sections explain these cases and possible countermeasures.
 
 
 ### Local ISD Kill Switch
 
-Compared to DNSSEC and BGPsec, a parent authority cannot switch off SCION core ASes, as they manage their own cryptographic trust roots. But executing a kill switch *inside* a local ISD can be done at different levels of the AS-level hierarchy:
+Compared to DNSSEC and BGPsec, a parent authority cannot switch off SCION core ASes as they manage their own cryptographic trust roots, but executing a kill switch *inside* a local ISD can be done at different levels of the AS-level hierarchy:
 
-- On TRC level: The private root keys of the root certificates contained in an TRC are used to sign the CA certificates. If one of these private root keys is compromised, the adversary could issue illegitimate CA certificates, which may be used in further attacks. To maliciously change the entire TRC through a TRC update is more complicated: Each TRC update requires multiple different voting keys. The number of comprimised voting keys needed to perform a malicious update of a TRC depends on the voting quorum set in the TRC. The higher the quorum, the more complicated maliciously updating a TRC will be.
+- On TRC level: The private root keys of the root certificates contained in an TRC are used to sign the CA certificates. If one of these private root keys is compromised, the adversary could issue illegitimate CA certificates which may be used in further attacks. To maliciously change the entire TRC through a TRC update is more complicated as each TRC update requires multiple different voting keys. The number of compromised voting keys needed to perform a malicious update of a TRC depends on the voting quorum set in the TRC: the higher the quorum, the more complicated malicious updating of a TRC will be.
 - On CA level: The private keys of an ISD's CA certificates are used to sign the AS certificates. All ASes within an ISD obtain certificates directly from the CAs. If one of the CA’s keys is compromised, an adversary could issue illegitimate AS certificates, which may be used in further attacks.
 - On AS level: Each AS within an ISD signs control-plane messages, such as the Path Construction Beacons (PCBs) used for path discovery, with their AS private key. If the keys of an AS are compromised by an adversary, this adversary can illegitimately sign control-plane messages, including PCBs. This means that the adversary can also manipulate the PCBs, and propagate the manipulated PCBs to neighboring ASes or register/store them as path segments.
 
@@ -1373,18 +1373,18 @@ The previous section describes possible "kill switches" on several levels within
 - On CA level: If the private key related to a CA certificate is compromised, the impacted CA AS must obtain a new CA certificate from the corresponding root AS. This process will vary depending on internal issuance protocols.
 - On AS level: In the event of a key compromise of a (non-core) AS, the impacted AS needs to obtain a new certificate from its CA. This process will vary depending on internal issuance protocols.
 
-If a core AS has not been compromised, but is instead acting maliciously (e.g., by not issuing or renewing certificates for certain ASes), one way to recover is for downstream ASes to self-organize and form a new ISD. By now operating autonomously, the new ISD can begin path discovery and traffic forwarding. SCION, unlike BGP, has no notion of routing convergence. Instead, the flooding of PCBs disseminates topology information. This means that in the worst case, if all paths must be re-created, fresh paths are established after a single flood has reached all ASes.
+If a core AS has not been compromised, but is instead acting maliciously (e.g., by not issuing or renewing certificates for certain ASes), one way to recover is for downstream ASes to self-organize and form a new ISD. By now operating autonomously, the new ISD can begin path discovery and traffic forwarding. SCION, unlike BGP, has no notion of routing convergence and instead the flooding of PCBs disseminates topology information. This means that in the worst case if all paths have to be re-created, fresh paths are established after a single flood has reached all ASes.
 
-**Note** that in the above case, it may not be clear whether the core AS acting as described is actually being malicious. It is the job of the core AS to enforce an ISD's policy. If a non-core AS within an ISD does not agree with the in itself legal behavior of the core ASes, it is up to the non-core AS to stay within the ISD - alternatively, the non-core AS could move to another ISD that suits it needs better.
+**Note** that in the above case, it may not be clear whether the core AS acting as described is actually behaving maliciously. It is the job of the core AS to enforce an ISD's policy. If a non-core AS within an ISD does not agree with ostensibly legal behavior of the core ASes, it is up to the non-core AS to stay within the ISD. Alternatively, the non-core AS could move to another ISD that suits its needs better.
 
 
 ## Denial of Service Attacks
 
 As described previously, the SCION's control-plane PKI lays the foundation for the authentication procedures in SCION. It provides each AS within a specific ISD with a certified key pair. These keys enable the authentication of all control-plane messages - every AS and endpoint can verify all control-plane messages by following the certificate chain.
 
-If an AS realizes that it misses any certificates, or that its certificates are no longer up-to-date (e.g., in case of certificate renewals and revocations), it must query the originator of the message for it. The same goes for an update of a TRC. Updated TRCs are not distributed actively, but must be discovered by the ASes within the ISD. This happens via the processes of beaconing and path-lookup (see also [](#discover-trcupdate)). Upon discovery of a new TRC, an AS must ask the sender of the message including the new TRC number for this new TRC.
+If an AS realizes that it is missing any certificates, or that its certificates are no longer up-to-date (e.g., in case of certificate renewals and revocations), it must query the originator of the message for these. The same goes for an update of a TRC as updated TRCs are not distributed actively, but must be discovered by the ASes within the ISD. This happens via the processes of beaconing and path-lookup (see also [](#discover-trcupdate)). Upon discovery of a new TRC, an AS must ask the sender of the message including the new TRC number for this new TRC.
 
-The above implies that the AS can *reach* the originating AS of the message, that is, that paths to the originator are available and that the relevant services at the originating AS are accessible. Denial of Service (DoS) attacks, where attackers overload different parts of the IT infrastructure, may impede this process of retrieving missing cryptographic material. However, the entire process of discovering of and requesting for missing cryptographical material is based on *control-plane* messages and communication. We therefore refer to {{I-D.scion-cp}} for a more detailed description of DoS vulnerabilities of control-plane messages.
+The above implies that the AS can *reach* the originating AS of the message, that is, that paths to the originator are available and that the relevant services at the originating AS are accessible. Denial of Service (DoS) attacks, where attackers overload different parts of the IT infrastructure, may impede this process of retrieving missing cryptographic material. However, the entire process of discovering and requesting missing cryptographical information is based on *control-plane* messages and communication. We therefore refer to {{I-D.scion-cp}} for a more detailed description of DoS vulnerabilities of control-plane messages.