Message-ID: <dea0003b-2402-40c3-97de-0e4598d94c90@felixguenther.info>
Date: Fri, 7 Mar 2025 16:45:07 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
References: <8349AE60-928D-4BCE-8924-EFAD25E4620A@ethz.ch>
 <AS5PR07MB9675B4B72C3E7956A5DCA1D089CA2@AS5PR07MB9675.eurprd07.prod.outlook.com>
From: =?UTF-8?Q?Felix_G=C3=BCnther?= <mail@felixguenther.info>
Autocrypt: addr=mail@felixguenther.info; keydata=
 xsDiBE04qkIRBADtFenVz1DuqethtPkoKAazBeKjyrr5Znbi8mQT1gOrkuli6i0/umf2uJ9V
 uI6NgjR0uM68UFGIHZlAoWk5Nfo8BTkYsdXl4R08pePmwRwwtq9LALZrGkeLeQtOFdLJt7G2
 iQgqq2XpZc9AXW3/+j0I6MmsWMQKCkCA1s6IRLtH+wCgk85oP1adRYaEpi82Z3oG7vztEOkE
 AMccj8RgnjWcbB13HxxRk2C/4mgLEmCBWO3nmcCPZP5t/5GZSe7Kt5HQoygjxxcro/2e+9wF
 YsYwLUpHKMOjyvtcU0jLtIv0m6I+GQ3HOz89erVpa7G7EUoEsbQ7FEuyW4mVEaQZ3XE1Mxvp
 /3Ca1rBJjoxXhxKaDJYWsc5fdO6RA/44xXLdiE2f6NDoTJY7Z97VXUnJskpDNnwePOJyX4GT
 DwII2kl6JSYOAmkcOpINOSVsS0XDLZpBuKqsibUF/t53BkNfR/aF/BzIUJ5dykqrHvi75aQb
 ltSum1+kIo8Q6ZI+MzAAwmbqLfuRHZP5y0fjxdHLhfMrvacrNHnaoUWrVc0oRmVsaXggR8O8
 bnRoZXIgPG1haWxAZmVsaXhndWVudGhlci5pbmZvPsJ8BBMRAgA8AhsjBgsJCAcDAgYVCAIJ
 CgsEFgIDAQIeAQIXgBYhBCuuSm95RkYbcAFhs1KvAgDT8XAOBQJdE93OAhkBAAoJEFKvAgDT
 8XAOVSwAn0QmRYzMtqFZejCnMakizqsaWHJlAJ4jR3nDqw5h3Ct4Xyz1CEQrUdJgz87DTQRN
 OKpCEBAA9TNoDOa0PVCAWvt9tw06MUw+D0PoAhkl1jlNEzeNatLDQqf6YehHOgtjpgA8tpul
 DJUq/o3NN15JsUB1el6oQje644owqhEFD8V02Ns3ZK6hGgBRGupp6RKwg70F4z4ukKwCS789
 rZdwaq8t+X37NRUP41Y537kgfN2R1BFLB0A19Qb52nsaneBUSgGLXu39bxDrHounoLjMitJa
 10ATRcuRny8eJzAuXI8lCURNjCPWJVjXN3gs+z6sA/ebr2inLQT66WIQZi5Q31BNyPGeaai+
 7t7IbpfkhqnbHATDq6vtM8lCem+rsYc3MtN1W4jQZ59ACI3ieu3MouMoN4W5mp0bjB6oNiO1
 TTYD3ZUYBeV7ITX47lag7A9MPzBwbRGdetAN1yU5HDv7mgadei/oFlwC4/hD18kYjuHEUxKi
 CookZZaPQEMTKjBpHhrphSslTXl/tWmMJBoVsgedghWyf39o8ZOTBsQQ1wHwhO9Dc+fwT/Q2
 Bw6jdZSzwQVJG13hg/uC6HqxhYfiKHtsiMuqnb5OIM0qkWa3Q/XtRclokk8elTjHYIIM+HBd
 i2xjys8D+1gVPI8s4NwPRAjc5m/kAXyzbrbg+p+ZVe3IJTE4M/heShLzsoFrZoroE2T38rvT
 Wsido/8zJZCxJ+JLAR8p8BYKYBJel/pHsvRFwSYbOEMAAwYP/j905vAZ/MJlLrElQ6eVwU2X
 IBhFmsOtQcVmh3CZw0QuXMA1AQsQe3KLLJSfBEP8Ljz8/Y9mPNu8wmvhw04Px0o7Ns6yOEuv
 v4CyQzaZwJGvn0lI4UajS7y4mgGFkd1AmPi1/4el9Yp4my88VlOcSe/macm4+MCIAMDegNLx
 JzErZgOMQJVdSz4rVYaWToTE/DVvRFkuEZgZNnvIv8G46OCZtnnRFv1XQDouxap2tO8yGBQ+
 BxBZXqrXtyeVz1weOBIVHycUxi9kGRQ5M99NfrZuInR1382W9YYhqiVgvmvWEsLZFRoGrh8w
 1yVkyxw6IGikWlkwq8TLGVlAiqA8AENZZ9bJJVOn57ld6Dvz8c8UvHpvSpUbt3Y3jf0GJbDn
 lj4v3ZrIxcI3RmUIGf0CQDSpqrUHppgKwiBPSLLRRQruGw7jzLpMqu7ar+2fhNQB3GLSmygi
 kdYXROfmIIq0J5g/rZLSFQ1GZmL3S8pqS9sJQh0KZEUE+1PtzAoYUYp9btR5Jo3pbyAn6M/g
 SNlSNDUwa2Eai6fy3fBu1KT1AYgntLzVyJr2Q/Wd85MjF/a9GI5X8lmnvPSAJ/ofSI/bRjLq
 yNj6frKLrztFV9ucWhKQoQd4iE9qe284KYqdQq4BZUhO4J2nl2rWbEquoFe9ACdIVBIuRoCH
 EUrreMG0tdymwkkEGBECAAkFAk04qkICGwwACgkQUq8CANPxcA6jYACfYd8EkV8G70iuPkyA
 HMZZ8W8lWUoAoJElB4EzU8opYiwQw02HRvW/qYuJ
To: cfrg@irtf.org
In-Reply-To: 
 <AS5PR07MB9675B4B72C3E7956A5DCA1D089CA2@AS5PR07MB9675.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID-Hash: LNSXEPPMQ675CXM3OXSQA6BC5FXPRQKX
Precedence: list
Subject: =?utf-8?q?=5BCFRG=5D_Re=3A_RGLC_on_draft-irtf-cfrg-aead-limits?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/cfrg/3P3CnhqsnEJ6rsRGxNOymwTz-uQ>

Hi John,

Thanks for taking the time to read and comment on the document.

I understand your concerns are primarily about the interpretation of 
single-key bounds and advantage bounds generally. We believe these can 
be mitigated by appropriate rewording in the draft.

Let me reply inline to the major points you raised.


On 2025-03-06 10:38 +0100, John Mattsson 
<john.mattsson=40ericsson.com@dmarc.ietf.org> wrote:
> I do NOT think the document should be published in the current state. I 
> think it is great to publish confidentiality advantages and integrity 
> advantages for algorithms. I do not agree at all with the drafts 
> suggestion on how to use the sigle-key advantages. I think these 
> sections should be removed. I think publishing the document in this 
> state do more harm than good.

We agree that single-key bounds are at odds with rekeying. This is in 
line with the core recommendation already stated in the draft: "When 
considering rekeying, the multi-user limits should be applied." We'll 
make sure this is emphasized more prominently.
(There's a confusing sentence on rekeying in the intro which we'll fix.)


> 
> Major:
> 
> - Any focus on single-key attacks for practical protcols makes little or 
> no sense. Single-key seldom occur in practice and the single-key 
> thinking should be phased out. Attackers will go for most 
> bang-for-the-buck and will do whatever gives most benefit for the least 
> amount of cost. Single--key is a theoretical simplification. Rekeying 
> based on single-key advantages turn the system into multi-key and may 
> easily lower security instead of increasing security.

Whether single keys are theoretical is a matter of threat model, and 
we'd hence keep the single-key limits for completeness. We'll add 
according cautionary wording, further emphasizing that multi-user bounds 
are to be used when rekeying.

> 
> - A gedankenexperiment using the suggested process suggest that the 
> ideal MAC should be rekeyed. This makes no sense.
> 
> - I don't agree with basing the limits on probabilities. I think attack 
> complexity and how small fraction of a bit an attacker can recover are 
> much better targets.For a PRP in counter mode an attacker cannot recover 
> more than ≈ σ^2 / 2^b bits of the plaintext.

We don't agree with plaintext recovery as a security target; the 
document specifically treats IND-CPA-style confidentiality. Arguably, 
this is a strong goal, but I don't think we should get into the 
territory of "what average fraction of bits is okay to leak"? (cf. also 
Dan's response on that)

> 
> - I also very much disagree with the suggested q limits in Table 2. I 
> think ANSSI's requirement to not encrypt more than 2^(b/2 - 5) blocks is 
> a well-thought-out and balanced requirement, effectively limiting the 
> amount of plaintext an attacker could recover to ≈ 1 / 2^10.47 ≈ 0.0007 
> bits. The limits in TLS 1.3, DTLS 1.3, and QUIC appear to be far 
> stricter than necessary. There is no universally agreed-upon threshold 
> for how much information an attacker must recover for it to constitute a 
> meaningful attack. However, protecting against the recovery of 1 / 
> 2^58.47 bits, a practically negligible fraction, seems overly cautious 
> and unlikely to be a realistic threat.
> 
> https://groups.google.com/a/list.nist.gov/g/ciphermodes-forum/c/tNlV34n3Vqw

We will emphasize that the numbers in Table 2 are exemplary, referring 
to TLS/DTLS/QUIC where similar (arguably conservative) choices have been 
made. The goal of this document is not to prescribe what level of 
security / adversary advantage is acceptable for a specific application; 
we'll also make this (more) explicit.

> 
> - I also very much disagree with the suggested v limits in Table 2. 
> These limits makes both the Bernstein bound and the expected number of 
> succesfull forgeries explode.
> 
> https://www.ietf.org/archive/id/draft-mattsson-cfrg-aes-gcm-sst-18.html

Not sure I'm following. All Table 2 says is that one can decrypt up to v 
= 2^46 messages to maintain a forgery probability of <= 2^-50.

> 
> I suggest that all suggestions on how to use the advantages is removed 
> from the documentand that the document is published as an overview of 
> confidentiality and integrity advantages.

We disagree on this, but will expand on emphasizing that specific 
usage/limits are examples, for certain (conservative) choices of 
advantages.


Regards,
Felix