I've fixed up the RFC references in 01 draft of https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/
As to the DKIM replay definition question, Murray noted that the DKIM RFC (RFC6376) already says something about DKIM replay as when they were writing it, they had suspected it could be a problem. It's only recently that it has become a real problem. -Wei On Tue, Oct 4, 2022 at 9:16 AM Alessandro Vesely <[email protected]> wrote: > On Tue 04/Oct/2022 02:01:12 +0200 Scott Kitterman wrote: > > > > Many normal email operations seem difficult to distinguish from the case > you are trying to address. Signing fields in the envelope may be enough to > break replaying, although it would have other negative consequences. > > > Scott is right. In general the envelope can contain jack@site-A and > jill@site-B. When the server connects to site-A, it only transmits > jack. Jill > would be rejected with something like "Relaying denied". So at site-A, a > signature including the envelope is already broken. > > About formatting, don't stuff like: > > ARC (RFC8617 (https://www.rfc-editor.org/rfc/rfc8617.html)) > > If using XML[*], write references like: > > ARC (<xref target="RFC8617"></xref>) > > Or, if using mmark[†]: > > ARC ([@!RFC8617]) > > > Best > Ale > -- > > [*] https://authors.ietf.org/references-in-rfcxml > [†] https://mmark.miek.nl/ > > > > > > > > _______________________________________________ > Ietf-dkim mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf-dkim >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
