[Rats] Re: [lamps] Re: Re: Freshness with Nonces

Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de> Fri, 21 June 2024 19:40 UTC

Return-Path: <muhammad_usama.sardar@tu-dresden.de>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDCCC14F6EF; Fri, 21 Jun 2024 12:40:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.407
X-Spam-Level:
X-Spam-Status: No, score=-4.407 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tu-dresden.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFZasaEO6hfe; Fri, 21 Jun 2024 12:40:32 -0700 (PDT)
Received: from mailout3.zih.tu-dresden.de (mailout3.zih.tu-dresden.de [141.30.67.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA05C14F61C; Fri, 21 Jun 2024 12:40:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-dresden.de; s=dkim2022; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:To:Subject:MIME-Version:Date:Message-ID:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NrrCaImUlhwQLdRMupDd/jX6iOO/hJX3guj0bR2qCOg=; b=mNKqOM30T4mKT0/yIcTtIxWOKx xTPn8fIfoGuABJRgQ/4qNA31aJtcqqKZBEYjqO7fULdlS7YZFieyDQwPWMJ5hc8fY8Wa5PVeZBz/r FjoxWS77X4LpIC60IdywWKX4aAi5+0kn5Kdo16ng1MYSgaz9rpoVKIwJLe+rf0eE5P8Av6J4hK4I7 bTbeJU2T2egSsE1m0SYShzhGeZf51gSIjSWdF/OPaf9W7ordSQ30EvUcvoM/WcovIb4G7D+ZPvsA6 67VBQD3eQaKGdvUhyJS0CZ+UOxn80GR7so/NQaWzcyg6YPU+ZtgpN5ukX/KJLYwB6SgVDK7POoLUX 5KTkHzcg==;
Received: from [172.26.35.114] (helo=msx.tu-dresden.de) by mailout3.zih.tu-dresden.de with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <muhammad_usama.sardar@tu-dresden.de>) id 1sKjor-00DPvU-UC; Fri, 21 Jun 2024 21:21:09 +0200
Received: from [10.0.0.102] (86.82.52.57) by MSX-T314.msx.ad.zih.tu-dresden.de (172.26.35.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Fri, 21 Jun 2024 21:21:00 +0200
Message-ID: <bfdf467e-2d22-41c6-ae3f-031ee8fda1be@tu-dresden.de>
Date: Fri, 21 Jun 2024 21:20:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Henk Birkholz <henk.birkholz@ietf.contact>, Carl Wallace <carl@redhoundsoftware.com>, "Tschofenig, Hannes" <hannes.tschofenig=40siemens.com@dmarc.ietf.org>, "spasm@ietf.org" <spasm@ietf.org>, rats <rats@ietf.org>
References: <3D0F8C7D-D1C6-4014-B69B-714771152A7E@redhoundsoftware.com> <533194ce-a8c3-2d41-9dbf-84f08f3afd84@ietf.contact> <f553a147-6eb4-47b9-bee0-5b518afe26da@tu-dresden.de> <9feef929-1405-83a0-d532-5d7cbe4cf5d8@ietf.contact>
Content-Language: en-US
From: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
In-Reply-To: <9feef929-1405-83a0-d532-5d7cbe4cf5d8@ietf.contact>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: msx-l318.msx.ad.zih.tu-dresden.de (172.26.34.118) To MSX-T314.msx.ad.zih.tu-dresden.de (172.26.35.114)
X-TUD-Virus-Scanned: mailout3.zih.tu-dresden.de
Message-ID-Hash: 3NTTBWNBUVUCGBRKGEXRBBIIXYCJ77Y4
X-Message-ID-Hash: 3NTTBWNBUVUCGBRKGEXRBBIIXYCJ77Y4
X-MailFrom: muhammad_usama.sardar@tu-dresden.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rats.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Rats] Re: [lamps] Re: Re: Freshness with Nonces
List-Id: Remote ATtestation procedureS <rats.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/Nsm_i6M_4Og5FkR26q_AloWheDY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Owner: <mailto:rats-owner@ietf.org>
List-Post: <mailto:rats@ietf.org>
List-Subscribe: <mailto:rats-join@ietf.org>
List-Unsubscribe: <mailto:rats-leave@ietf.org>

Hi Henk,

your short sentences seem to be missing some context. So I still don't 
fully understand what you are saying.

On 21.06.24 12:18, Henk Birkholz wrote:
> Hi Usama,
>
> you cannot check freshness or recentness. 
"with signatures alone" I guess, right?
> But if you recognize a unique signature (and remember them in "state") 
> then you can avoid replay attacks. 
Where does this uniqueness of signature come from? The only two possible 
inputs of signature are the signing key and the data. Assuming the 
signing key remains the same, the only source of uniqueness is the data. 
And that is what I mentioned below that unless some freshness context 
(such as nonce or timestamp) is added to the signing data, how can the 
verifier check the freshness?
> That is of course not always feasible, but if you can "remember" 
> nonces, you can also remember signatures - in the context of replay 
> attacks. 
I don't immediately see any benefit of storing signatures rather than 
nonces. Can you illustrate a few benefits?

Regards,

Usama

>
> On 19.06.24 21:06, Muhammad Usama Sardar wrote:
>> Hi Henk,
>>
>> On 19.06.24 20:41, Henk Birkholz wrote:
>>> for example, signatures can be used for replay attack detection, 
>>> too. I think you do not need nonces for that at all.
>>
>> I don't think that is correct. How can signatures /alone/ be used for 
>> /replay/ attack detection? Unless some freshness context (such as 
>> nonce or timestamp) is added to the data that is signed, you can 
>> replay it forever.
>>
>> Usama
>>