On Mon, Jul 16, 2018 at 7:06 AM, Jim Fenton <[email protected]> wrote:
> 9.2 describes the problem, but it's expressed in terms of a DoS attack on > (primarily) validators. The DNS folk will be more concerned with the > overall load on the infrastructure caused by ARC, not specifically on > attack scenarios. So in consulting the DNS directorate, it would be good to > mention the operational impact of 9.2. > > I also wonder if it would be helpful to mitigate the operational impact by > saying that AS SHOULD use the same selector as the associated AMS. > This has also been discussed several times on list, here's one such: https://mailarchive.ietf.org/arch/msg/dmarc/XfS4UnLPrMbIhTvjYjmsYrcj_HA Where this reach consensus (and it wasn't in the referenced thread, but I couldn't find it after a brief search), was that no one had any technical reason for a MUST or even a SHOULD in the spec, and that ultimately this is matter of usage. So the usage guide should say that AMS and AS d=/s= should match UNLESS you have a good reason to do otherwise, as receivers will most likely treat it as suspicious if they don't. We could see a clear example where the ARC Seal is signed by the organizational entity, and the ARC Message Signature is signed by the service. For instance, AS d=example.org, and AMS d=examplelists.org. This translates to my ADMD takes overall responsibility for handling this message, and this service within made a breaking change. This seemed to be something that would become clear through the Experiment, if everyone used the same key for both, then we could simplify the specl. But if using separate keys ended up being valuable, and didn't create a meaningful increase in DNS overhead, there was no reason to prohibit it before seeing where the chips fell.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
