Copy-edit CVE responses.

SECURITY/CVE-2019-13678

@@ -7,55 +7,64 @@ Link: https://nvd.nist.gov/vuln/detail/CVE-2019-16378
 
 Background Details: 
 
-When implemented, the DMARC RFC (RFC7489) assumed that emails with multiple 
-From: fields would be rejected by the receiving MTA (Section RFC7489 section 
-6.6.1), and that emails containing such a header would be rare in practice.  
+When it was written, the DMARC RFC (RFC 7489) assumed that emails with multiple 
+addresses in the From: field would be rejected by the receiving MTA
+(Section RFC 7489 section 6.6.1), and moreover that emails containing such
+a header field would be rare in practice.
 
 In the case where such a message is received, the RFC recommends (in the 
-same section) that both domains be tested, and the strictest policy be 
+same section) that all domains be tested, and the strictest policy be 
 applied.
 
-However, having two distinct administrative domains in the same From: 
+However, having even two distinct administrative domains in the same From: 
 header (for example, [email protected], [email protected]) leads to an issue: 
 
-For SPF, mail can only be delivered to a receiving system from one IP.  
-Unless that IP address is (coicidentally or intentionally) in both 
-domains' spf records (or the domains include: each other), then the SPF 
-check will fail (forged HELO's notwithstanding).
+* For SPF, mail can only be delivered to a receiving system from one IP  
+  address.  Unless that IP address is (coicidentally or intentionally) in both 
+  domains' SPF records (or the domains "include:" each other), then the SPF 
+  check will fail (forged HELO's notwithstanding).
 
-For DKIM, there can only be one selector/domain in a given DKIM-Signature, 
-referencing a single "From:" header.  So in the case where either domain 
-specifies a dmarc policy of either p=reject or p=quarantine, the result 
-will be a failure.
+* For DKIM, there can only be one selector/domain in a given DKIM-Signature, 
+  referencing a single "From:" header.  So in the case where either domain 
+  specifies a DMARC policy of either p=reject or p=quarantine, the result 
+  will be a failure.  The message would have to bear valid signatures
+  from both domains.
 
 In practice, citing the example above, a message cannot have been signed 
 as being delivered to a receiving system immediately after originating from 
 both gmail.com and hotmail.com.  While it's possible to have a message
 relayed *through* one system via another, this is not what DMARC attempts
-to solve, and is what ARC is for.
+to solve, and is what ARC (RFC 8617) is for.
 
-RFC7489 Also states (section 3.1.1):    Note that a single email can contain 
+RFC 7489 also states (Section 3.1.1): Note that a single email can contain 
 multiple DKIM signatures, and it is considered to be a DMARC "pass" if any 
 DKIM signature is aligned and verifies.
 
 The behavior of a case of there being multiple distinct domains does not 
 appear to have been considered by this section, as it seems to apply to
 multiple signing agents inside a single administrative domain.
 
+There are additional concerns.  A filter that attempts to perform a full
+DMARC evaluation of every domain found in a multi-valued From could be used
+to amplify a denial of service attack either against the system running
+the filter or against other nameservers by intentionally listing a large
+number of domains in the From field.  The specification does not
+provide guidance to mitigate such abuse.
+
 Resolution:
 
-Doing all the DMARC checks for every domain in the From: of a message adds 
+Doing all of the DMARC checks for every domain in the From: of a message adds 
 additional complexity, and opens a vector for abuse.
 
 In the case where a message contains two or more From: addresses from the 
-same domain: (For example, "From: [email protected], [email protected]"), 
+same domain (for example, "From: [email protected], [email protected]"), 
 both processed and signed by science.edu's mail server, these messages will 
-be processed as normal, so long as there is only one unique domain).
+be processed as normal, so long as there is only one unique domain.
 
 For all other cases, OpenDMARC has added an option to outright reject messages 
 containing a multi-valued From: field.  If set, messages can be rejected at 
 receipt-time.  If unset, messages will be ignored by the filter.  (They will 
 not pass, but they will not fail).
 
 The Authentication results field added in this case will have a result of 
-dmarc=permerror.
+dmarc=permerror.

SECURITY/CVE-2019-20970

@@ -1,35 +1,41 @@
-
 CVE-2019-20790 - OpenDMARC through 1.3.2 and 1.4.x, when used with 
 pypolicyd-spf 2.0.2, allows attacks that bypass SPF and DMARC 
 authentication in situations where the HELO field is inconsistent 
 with the MAIL FROM field.
 
 Link: https://nvd.nist.gov/vuln/detail/CVE-2019-20790
 
-Details: While the SPF RFC (RFC7208) says that entities MUST check 
-the "Mail From" header during an SPF check (RFC7208 section 2.4).  
-
-Section 2.3 says and that checking the HELO/EHLO string is RECOMMENDED.  
+Details: While the SPF RFC (RFC 7208) says that entities MUST check 
+the envelope sender during an SPF check (Section 2.4), Section 2.3 also
+says that checking the HELO/EHLO string is RECOMMENDED.  
 
-It further states (section 2.3): 
+It further states (Section 2.3): 
 
-If a conclusive determination about the message can be made based on 
-a check of "HELO", then the use of DNS resources to process the typically 
-more complex "MAIL FROM" can be avoided.
+    If a conclusive determination about the message can be made based on 
+    a check of "HELO", then the use of DNS resources to process the typically 
+    more complex "MAIL FROM" can be avoided.
 
 The HELO string is trivially forgeable and can be set to any value by 
 anyone delivering mail to a system.  It does not depend on the hostname 
-of the transmitting system.
+of the transmitting system.  There is no guarantee that the HELO value
+will be validated by the receiving system.  Moreover, RFC 5321 (the
+current SMTP specification) says:
+
+    An SMTP server MAY verify that the domain name argument in the EHLO
+    command actually corresponds to the IP address of the client.
+    However, if the verification fails, the server MUST NOT refuse to
+    accept a message on that basis. 
 
 Resolution/Workaround: It is the job of OpenDMARC to trust information 
 provided to it by upstream filters.   OpenDMARC itself can be configured 
-to validate SPF, but there are use-cases where OpenDMARC may be running 
+to validate SPF, but there are use cases where OpenDMARC may be running 
 further inside a network and not have access to the connection strings as 
-logged.
+logged.  No standard exists for relaying the IP address of the client
+to inward systems when relaying occurs.
 
 It is the view of the OpenDMARC developers that this is working as 
-designed, but if this behavior is undesirable, then any filter which adds 
-a received-spf header should not set a spf=pass result based solely on the 
-HELO/EHLO string.  It is not the job of OpenDMARC to second-guess other 
+designed, but if this behavior is undesirable, then any filter that adds 
+a Received-SPF header field should not set a spf=pass result based solely on
+the HELO/EHLO string.  It is not the job of OpenDMARC to second-guess other 
 filters in the chain, but simply to compare their stated values and make 
-a weight-based judgement.
+a weight-based judgement.

SECURITY/CVE-2020-12272

@@ -1,15 +1,14 @@
-
 CVE-2020-12272 - OpenDMARC through 1.3.2 and 1.4.x allows attacks
 that inject authentication results to provide false information 
-about the domain that originated an e-mail message. This is caused
+about the domain that originated an e-mail message.  This is caused
 by incorrect parsing and interpretation of SPF/DKIM authentication 
-results, as demonstrated by the example.net(.example.com substring.
+results, as demonstrated by the "example.net(.example.com" substring.
 
 Link: https://nvd.nist.gov/vuln/detail/CVE-2020-12272
 
 Resolution: OpenDMARC has added checking to validate that the domain
 element in both SPF and DKIM headers being inspected argument contains 
 only valid domain name characters.  This has been fixed as of
 OpenDMARC 1.4.1 (March 2021).  While not mentioned in the CVE, fixes 
-are in a soon-to-be released branch of OpenDKIM as well to not put such a 
-malformed header in place.
+are in a soon-to-be released branch of OpenDKIM as well so that a
+signature bearing such a domain will be considered invalid.

SECURITY/CVE-2020-12460

@@ -8,4 +8,4 @@ chunk and its PREV_INUSE flag.
 Link: https://nvd.nist.gov/vuln/detail/CVE-2020-12460
 
 Resolution: OpenDMARC has repaired the function in question, as of 
-OpenDMARC 1.4.0 (January 2021)
+OpenDMARC 1.4.0 (January 2021).