Re: [dmarc-ietf] third party authorization, not, was non-mailing list

Alessandro Vesely <vesely@tana.it> Sun, 30 August 2020 16:11 UTC

Return-Path: <vesely@tana.it>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F7E3A0BA3 for <dmarc@ietfa.amsl.com>; Sun, 30 Aug 2020 09:11:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.046
X-Spam-Level:
X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chLW4bnRntyZ for <dmarc@ietfa.amsl.com>; Sun, 30 Aug 2020 09:11:05 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58033A0BA4 for <dmarc@ietf.org>; Sun, 30 Aug 2020 09:11:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1598803860; bh=pvHIEnnd/WDveQHKTWpmbL9HnvcGxfaZ/hHm3cQhMXo=; l=1834; h=To:References:From:Date:In-Reply-To; b=AjpJwSliJAxoMOw9f9P1YLkb3BeukrtWlxg162x6CjcXkv+5pQuNZsSXMnk3hToeS ceDpRyDva7wpVo2DdI1FJsMFdMHO1hO39lzXiTk1DNMGFxzy6e8Mow6ynJNMNAGZvB XVIUhdpyTuA1nYSfiW3ZQi1i0K9vsTuSpYtWlW1eR3JyIG4FT9qZXiKq+qvYG
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005F4BCF94.00001212; Sun, 30 Aug 2020 18:11:00 +0200
To: dmarc@ietf.org
References: <7e71edd41d84410380879149d0962096@com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <f12f2a98-f21a-d0eb-0fdf-5c84d6e5d8d9@tana.it>
Date: Sun, 30 Aug 2020 18:11:00 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <7e71edd41d84410380879149d0962096@com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/UpwHQGsODkoHbgXtgypzbR3hWmo>
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Aug 2020 16:11:08 -0000

On Sun 30/Aug/2020 14:07:33 +0200 Douglas E. Foster wrote:
> Since we are designing a system that allows a mediator to alter Subject and 
> Body, it should be no surprise that the conditional signature has the potential 
> for re-use.   A well behaved mediator must be assumed before any such trust 
> delegation is granted.
> 
> I see no way to ensure that the conditional signature is single-use. As long as 
> all of the signature's hashed content can be replicated onto another message, 
> the signature can be reused.


Yes.  That's true for any DKIM signature, in particular if using l=, which 
allows to append varying content.


> The more important question is whether conditional signature could be subject 
> to third-party attacks.  Does the limited and predictable content of a 
> conditional signature intcrease the risk that a bad guy could use 
> guess-and-test to construct a valid  signature block for someone else?


If you have the signature, you presumably have the whole message.  So there's 
no need to guess.  It is enough to keep signed header fields, presumably From:, 
Message-Id: (which is random, btw), and Date:.  All the rest can be changed at 
will.


> DKIM uses the body content in two different hash calculations.  This severely 
> limits the ability of an attacker to find and exploit a hash collision.   The 
> conditional  signatures seem unlikely to have that strength.


Even if the hash covers few data, finding a collision is not any easier.

According to dkim-conditional, an attacker would need a private key of the 
domain pointed by !fs=.  That limits exploits substantially.  Using vanilla 
weak signatures (e.g. to be compatible with v=1 verifiers) allows replaying at 
recipient's discretion, a state of affairs loosely comparable to p=none.



Best
Ale
--