On Wed, May 31, 2017 at 3:22 PM, Murray S. Kucherawy <[email protected]> wrote:
> On Wed, May 31, 2017 at 3:08 PM, Brandon Long <[email protected]> wrote: > >> On Wed, May 31, 2017 at 1:42 PM, Murray S. Kucherawy <[email protected] >> > wrote: >> >>> On Wed, May 31, 2017 at 1:35 PM, Murray S. Kucherawy < >>> [email protected]> wrote: >>> >>>> What benefit is there to covering AAR with both the AMS and the AS? It >>>> seems to me the AMS is much cleaner (in the sense of ARC being a layer atop >>>> DKIM) if it is purely a renamed DKIM signature with an instance number. >>>> >>>> Put another way, the apparent intent here is to require that things be >>>> generated in a specific order (AAR, then AMS, then AS) but it seems to me >>>> there's no obvious benefit to imposing that constraint given that AS is >>>> supposed to cover everything anyway. >>>> >>> >> Ignoring your DKIM bit, I can also see how this could be extended to >> think about the oddness that having two signatures and whether the keys >> need to match between AS/AMS. >> >> One could imagine that the AMS was just a hash, and it would be a single >> signature in the AS which covers it. That's obviously more different than >> DKIM, but reduces the size of the headers and makes a single point of >> ownership. >> > > Indeed, AS could sign (a) a locally-generated DKIM signature, with an > instance tag (since DKIM validators ignore tags they don't know), plus (b) > the current and all previous AAR/AS fields. > That's kind of the opposite direction of what I was thinking. I'm saying, an AMS doesn't need a b= field, it could instead have an hh field (header hash) or replace bh with a single hash field. ARC-Seal: i=1; a=rsa-sha256; t=1496269322; cv=none; d=google.com; s=arc-20160816; b=dttRxs73FHsET5Zu1FVFwkpnS2bLmNcCXJKMBS5JPwBdfNIqBK7RH2P9K9SzXaBtg4 rpXyIA+nigy2vHiKAP0hU8Cbh2lUtHXQbglvSiom91w+8UpDvvlGI8N4OP7Ju0iAvmfS XAxPGuXKCiyd48jZ+9QOqP1q39gd1mheUrkmFoVYzd9n5bkfwkazhkT05gk1bs16fnE4 1fvOasGjlBvhDEzSv790k7i40NpwXuYRqhYgD3/ndxfT0l/uVJ0qp44krz0yRgyJebjo oNOeJT1dFL3l70BPnDtku5Wof77eD1Ql8rb5uGKnRgpYaaxh2Nt5PNQ0iLtFBWFTQo9c GL2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:dkim-signature:arc-authentication-results; hash=3Yg5aVXobpP5fEP6VLnpuEPddr3SuybR7iVPPBvW59s= ARC-Authentication-Results: i=1; mx.google.com; dkim=pass [email protected]; spf=pass (google.com: domain of [email protected] designates 2607:f8b0:400c:c05::22c as permitted sender) smtp.mailfrom= [email protected]; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com This removes the confusion over separate s/d for AMS/AS, reduces the size of the headers added by ARC, reduces the cost of signing/verifying (one less encryption step, though that may not be the expensive part). Ie, our current idea was the onion wrapping, AS wraps AMS which wraps AAR. If we think more of them as a unit, then the signature in the AS is sufficient for the whole unit. Hm, though then, maybe it's not a Message-Signature but just a Message-Hash. Brandon
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
