Re: [dmarc-discuss] DMARC vs DKIM keys with s=mtasts

[Scott Kitterman via dmarc-discuss]

On March 29, 2020 10:36:50 PM UTC, John Levine <jo...@taugh.com> wrote:
>In article <3074162.RNaZIRUnTP@l5580> you write:
>>RFC 6376, Section 3.6.1, in the s= paragraphs says:
>>
>>> *  matches all service types
>>
>>If libopendkim and Mail::DKIM are looking for a literal '*' as the
>service 
>>type, rather than accepting any value for service type, they are buggy
>and 
>>should be fixed AFAICT.
>
>If there's an s= tag, they accept "*" or a colon separated list that
>contains "email".  My locally patched libopendkim does what pydkim
>does and also accepts a list with "tlsrpt".
>
>The language in 6376 says if a key record has an s= tag and it doesn't
>have a value we like, we ignore the record.  That's why the DKIM
>signatures with s=tlsrpt don't validate, since that's not a key that's
>valid for the 'email' service.
>
>>> RFC 8460 says the key SHOULD have s=tlsrpt and the recipient MAY
>ignore
>>> reports without that service type.  I'm inclined to consider that an
>error
>>> in view of experience with it.  Different service types are for
>messages
>>> delivered some way other than SMTP.
>>
>>I'm not sure that follows if service types are correctly processed.  I
>am 
>>curious what you think it a kludge in dkimpy?
>
>Since RFC 8460 doesn't update 6376, I'm confident that an s=tlsrpt key
>shouldn't validate a signature on ordinary e-mail not intended as a
>TLS report.  Arguably, it shouldn't validate e-mail even if it *is*
>intended as a report, since the spec says s= is there for "other
>services" and TLS reports aren't another service, they're e-mail.  If
>you want to make RFC 8460 happy, add another signature separate from
>the one that email uses.
>
>My recollection from back when that language was written 15 years ago
>is that we meant service in the RFC 6335 sense, different things that
>would never show up in the same stream as e-mail messages.  The
>specific example was signing SIP headers, which I think would have
>been a better idea than much more complex STIR/SHAKEN.  It still might
>be interesting to put DKIM signatures on HTTP messages.

I don't think 8460 needed to update 6376, since valid service values are 
defined by the registry, not by 6376.  The mistake was not updating the 
registry.

After looking at it again, I see your point about ignoring unknown service 
types.  I agree a second signature for regular email stream validation (e.g. 
DMARC) would make sense.

Scott K

_______________________________________________
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)