Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers
On Tue 07/Apr/2020 09:09:01 +0200 Damian Lukowski wrote: Authentication-Results: domain.tld, spf=pass smtp.mailfrom=x@y.z >>> >>> Needs to be removed? I say no. >> >> >> Yes, and log it. > > Please notice the comma instead of the semicolon, it wasn't a typo. > Would you still remove it? If I can lazily (or sloppily) identify it as an authserv-id, so can do other tools too. >> Both cases are renamed to Old-Authentication-Results anyway. The part that >> would log it, however, doesn't recognize the quotes (I'm going to fix it now) >> and intermittently removes the header. > > I wanted to object that the RFC does not allow to tamper with "innocent" > headers, but it actually does not forbid it. That said, I could even > remove previous A-R headers altogether and be RFC compliant, so a lazy > evaluation parser can be compliant as well. IMHO that's the simplest approach. By renaming (otherwise obscuring) instead of deleting you still leave room for debugging and forensics. >> Note2: even if a tool accepted a list of trusted authserv-id's, consider a >> MUA >> simultaneously accessing two mailboxes, at example.com and example.org, say. >> Of course you would configure the tool to trust both of their authserv-id >> (which is already beyond what an average user is willing to configure). >> Then, >> a malicious party can send you a message at your @example.com address, >> bearing >> a faked Authentication-Results by example.org. Should the tool trust it? > > Wouldn't a trust-list per mailbox solve the issue, instead of a global > trust-list? Per-mailbox lists might seem to do it. However, consider, in the above scenario, making the decision to forward some or all of your @example.org traffic to your example.com mailbox, directly from example.org server. Now you'd want to trust example.org A-Rs even when they arrive through example.com. The only easy way that I see to accomplish that is to instruct example.com to whitelist example.org's A-R; if example.com admins trust example.org, that is: For simplicity and maximum security, a border MTA could remove all instances of this header field on mail crossing into its trust boundary. However, this may conflict with the desire to access authentication results performed by trusted external service providers. [...] A more robust border MTA could allow a specific list of authenticating MTAs whose information is to be admitted, removing the header field originating from all others. https://tools.ietf.org/html/rfc8601#section-5 Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers
>>> Authentication-Results: domain.tld, spf=pass smtp.mailfrom=x@y.z
>>
>> Needs to be removed? I say no.
>
>
> Yes, and log it.
Please notice the comma instead of the semicolon, it wasn't a typo.
Would you still remove it?
>>> Authentication-Results: domain.tld; {garbage}
>>
>> Needs to be removed? I say no.
>
> Yes, and log it.
Interesting, you suggest to parse "lazily", i.e. as soon as a token
looks like an authserv-id, treat it as such.
> Both cases are renamed to Old-Authentication-Results anyway. The part that
> would log it, however, doesn't recognize the quotes (I'm going to fix it now)
> and intermittently removes the header.
I wanted to object that the RFC does not allow to tamper with "innocent"
headers, but it actually does not forbid it. That said, I could even
remove previous A-R headers altogether and be RFC compliant, so a lazy
evaluation parser can be compliant as well.
Thanks.
> Note that some tools, e.g. Thunderbird DKIM-Verifier[*] can be configured to
> either "Read Authentication-Results header" or not. Hence is makes sense to
> rename all on entry.
>
> Note2: even if a tool accepted a list of trusted authserv-id's, consider a MUA
> simultaneously accessing two mailboxes, at example.com and example.org, say.
> Of course you would configure the tool to trust both of their authserv-id
> (which is already beyond what an average user is willing to configure). Then,
> a malicious party can send you a message at your @example.com address, bearing
> a faked Authentication-Results by example.org. Should the tool trust it?
Wouldn't a trust-list per mailbox solve the issue, instead of a global
trust-list?
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers
On Fri 03/Apr/2020 22:42:23 +0200 Damian Lukowski wrote:
>> The system should remove the quotes when comparing, and should also do
>> any decoding to get the admds into the same format.
>
> My question's intent was not particularly about the quotes and UTF-8, I
> just chose it, because the syntactically invalid version looks more
> legit than the syntactically valid one. Assume some plain-ASCII
> examples. A mail system with own authservid of domain.tld receives mail
> with:
My system, my rules:
>> Authentication-Results: domain.tld; spf=pass smtp.mailfrom=x@y.z
>
> Needs to be removed? Clearly yes.
Yes, and log it.
>> Authentication-Results: otherdomain.tld; spf=pass smtp.mailfrom=x@y.z
>
> Needs to be removed? Clearly no.
Rename the header field to Old-Authentication-Results anyway.
>> Authentication-Results: {garbage}
>
> Needs to be removed? I say no.
Rename the header field to Old-Authentication-Results anyway.
>> Authentication-Results: domain.tld, spf=pass smtp.mailfrom=x@y.z
>
> Needs to be removed? I say no.
Yes, and log it.
>> Authentication-Results: domain.tld; {garbage}
>
> Needs to be removed? I say no.
Yes, and log it.
>> Authentication-Results: "domain.tld"; {garbage}
>
> Needs to be removed? I say no.
>
>> Authentication-Results: "domain.tld"; spf=pass smtp.mailfrom=x@y.z
>
> Needs to be removed? Yes.
Both cases are renamed to Old-Authentication-Results anyway. The part that
would log it, however, doesn't recognize the quotes (I'm going to fix it now)
and intermittently removes the header.
Note that some tools, e.g. Thunderbird DKIM-Verifier[*] can be configured to
either "Read Authentication-Results header" or not. Hence is makes sense to
rename all on entry.
Note2: even if a tool accepted a list of trusted authserv-id's, consider a MUA
simultaneously accessing two mailboxes, at example.com and example.org, say.
Of course you would configure the tool to trust both of their authserv-id
(which is already beyond what an average user is willing to configure). Then,
a malicious party can send you a message at your @example.com address, bearing
a faked Authentication-Results by example.org. Should the tool trust it?
jm2c
Ale
--
[*]
https://www.reddit.com/r/Thunderbird/comments/5nheej/is_it_possible_to_make_thunderbird_display_the/
(The "Edit 2" is bogus, but the previous edit describes the point well.)
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers
> Honestly, it doesn't matter. The only A-R headers you can trust are > the ones that your own system added, and the point of that text is > that you should delete ones that look like yours but that you didn't > add. How can a MUST not matter? My personal interest in this area is what needs to be done according to the specification, which unfortunately uses a metaphoric verb for the condition of the MUST. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers
> The system should remove the quotes when comparing, and should also do
> any decoding to get the admds into the same format.
My question's intent was not particularly about the quotes and UTF-8, I
just chose it, because the syntactically invalid version looks more
legit than the syntactically valid one. Assume some plain-ASCII
examples. A mail system with own authservid of domain.tld receives mail
with:
> Authentication-Results: domain.tld; spf=pass smtp.mailfrom=x@y.z
Needs to be removed? Clearly yes.
> Authentication-Results: otherdomain.tld; spf=pass smtp.mailfrom=x@y.z
Needs to be removed? Clearly no.
> Authentication-Results: {garbage}
Needs to be removed? I say no.
> Authentication-Results: domain.tld, spf=pass smtp.mailfrom=x@y.z
Needs to be removed? I say no.
> Authentication-Results: domain.tld; {garbage}
Needs to be removed? I say no.
> Authentication-Results: "domain.tld"; {garbage}
Needs to be removed? I say no.
> Authentication-Results: "domain.tld"; spf=pass smtp.mailfrom=x@y.z
Needs to be removed? Yes.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers
In practice, I don't know how common it is for clients to consume this header. They have to if they're adding ARC seals on the way out. Only if the ADMD's particular implementation to pass through the information from incoming perimeter system to outgoing perimeter system happens to utilize the A-R header(s) for the purpose of conveying that information. It would seem pretty perverse to create an AAR header with exactly the same info as the AR header by ignoring the AR header. But whatever. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers
On Fri, Apr 3, 2020 at 1:09 PM John Levine wrote: > In article < > caba8r6sbhlfkzhd4gapbxqbgny57j1elxt2spyafatyay3t...@mail.gmail.com> you > write: > >In practice, I don't know how common it is for clients to consume this > >header. > > They have to if they're adding ARC seals on the way out. > Only if the ADMD's particular implementation to pass through the information from incoming perimeter system to outgoing perimeter system happens to utilize the A-R header(s) for the purpose of conveying that information. --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers
In article you write: >In practice, I don't know how common it is for clients to consume this >header. They have to if they're adding ARC seals on the way out. Other than that I don't have much idea either. On my system my mailing list software looks at it them to decide how much DMARC hackery to do but again I don't know how common that is. Since the point of the text is that you can only trust your own A-R headers, presumably the code that adds them and that consumes them are at least partly under the same management so I'd think they could agree on their quoting practices. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers
In article you write: >> this specification MUST delete any discovered instance of this header >> field that claims, by virtue of its authentication service >> identifier, to have been added within its trust boundary but that did >> not come directly from another trusted MTA. > >In my opinion, a header that does not conform to the specified >authres-header-field in the RFC, is not an Authentication-Results >header, has no authentication service identifier, and as such cannot >claim anything in the context of the RFC. ... Honestly, it doesn't matter. The only A-R headers you can trust are the ones that your own system added, and the point of that text is that you should delete ones that look like yours but that you didn't add. We leave other people's A-R headers in case they might be useful to do forensics, and we have a slightly different version of them in ARC chains which again are only trustworthy if you know who added the ARC seals. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers
RFC8601 sec 5 states: > any MTA conforming to > this specification MUST delete any discovered instance of this header > field that claims, by virtue of its authentication service > identifier, to have been added within its trust boundary but that did > not come directly from another trusted MTA. In my opinion, a header that does not conform to the specified authres-header-field in the RFC, is not an Authentication-Results header, has no authentication service identifier, and as such cannot claim anything in the context of the RFC. So suppose there is a mail system with an UTF-8-non-ASCII authserv-id. When creating its own A-R headers, it puts the authserv-id into quotes, because it cannot use it without them, as discussed in the separate thread. What should the system do with an A-R header of an inbound message that incorporates the system's authentication service identifier without using quotes, but that otherwise would be syntactically correct? Again in my opinion, the system needs to keep the header, but what is the RFCs intention? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
