Post AiY0CJvSnFc8D7Pg1I by vftdan@mastodon.ml
 (DIR) More posts by vftdan@mastodon.ml
 (DIR) Post #AiY0CH0fdQzrAOpIDg by vftdan@mastodon.ml
       2024-06-03T09:24:33Z
       
       0 likes, 0 repeats
       
       What if static HTTP without encryption, but with signatures? It could benefit from non-authoritative caching proxies without being prone to active attacks performed by proxy operators.
       
 (DIR) Post #AiY0CIkn9RU2ZjPdkO by dside@mastodon.ml
       2024-06-03T09:49:45Z
       
       0 likes, 0 repeats
       
       @vftdan working draft from W3C: https://www.w3.org/TR/WD-sigs
       
 (DIR) Post #AiY0CJvSnFc8D7Pg1I by vftdan@mastodon.ml
       2024-06-03T09:43:26Z
       
       0 likes, 0 repeats
       
       Using an anonymizing proxy that wraps an encrypted connection to the caching proxy might be strongly recommended.
       
 (DIR) Post #AiY0CK3GKFqubJ3uAy by lyyn@mastodon.ml
       2024-06-03T10:17:34Z
       
       0 likes, 0 repeats
       
       @dside @vftdan I am of opinion that in most circumstances where signatures are desired non-repudiation is actually NOT desired. If non-repudiation is the cost of allowing caching it might be not worth it in the end.
       
 (DIR) Post #AiY0h6NRDXgvAPAxWK by dside@mastodon.ml
       2024-06-03T10:23:10Z
       
       0 likes, 0 repeats
       
       @lyyn 1. How can you possibly have a signature without non-repudiation? If a signature exists, it was either generated by the owner of the key or the signature mechanism is vulnerable to forgery.2. How does non-repudiation impede caching?@vftdan
       
 (DIR) Post #AiY14EcEkhaRNZ81g0 by lyyn@mastodon.ml
       2024-06-03T10:27:20Z
       
       0 likes, 0 repeats
       
       @dside @vftdan 1. MACs and Diffie-Hellman, that's how it is done in OTR, Signal Protocol, etc.2. Non-repudiation does not impede caching, repudiability does. Because for example Diffie-Hellman requires synchronous per-request communication.
       
 (DIR) Post #AiY1Zxk31bakJOuXRI by lyyn@mastodon.ml
       2024-06-03T10:33:04Z
       
       0 likes, 0 repeats
       
       @dside @vftdan (For 1. actually I should remind that TLS does NOT provide non-repudiation either)
       
 (DIR) Post #AiY1bZZtpstNwsvqVM by dside@mastodon.ml
       2024-06-03T10:33:22Z
       
       0 likes, 0 repeats
       
       @lyyn DH is a mechanism for key negotiation, not signing. It does not produce signatures at any point.MACs aren't signatures either.@vftdan
       
 (DIR) Post #AiY24CF1gDrxy9ojtw by lyyn@mastodon.ml
       2024-06-03T10:38:32Z
       
       0 likes, 0 repeats
       
       @dside @vftdan Signatures are just a method for providing integrity, just as Diffie-Hellman + MACS are. I think we can agree that we are seeking integrity. TLS provides integrity. Signal Protocol provides integrity. But they don't provide non-repudiation and I think it's a good thing, because it's unnecessary and harmful outside of legal documents.
       
 (DIR) Post #AiY3U8yaXfnXKH46qW by lyyn@mastodon.ml
       2024-06-03T10:54:26Z
       
       0 likes, 0 repeats
       
       @dside And yes, that's right. MACs need a shared key, which you get from authenticated Diffie-Hellman. That's one way of achieving integrity without non-repudiation.
       
 (DIR) Post #AiY42GwdQDWdsyQQZk by dside@mastodon.ml
       2024-06-03T11:00:29Z
       
       0 likes, 0 repeats
       
       @lyyn no. The whole point of a signature is for its generation to be impossible for anyone but the signer. Meaning non-repudiation is baked into signatures *by definition*. Full stop.MACs use the same keys for both generation and verification, meaning they're only usable in narrow circles of generators and verifiers that can negotiate a key and keep it secret among themselves. That's what allows repudiation there — being able to verify a MAC means you can also forge it, and there's no way to tell after the fact if it happened on a given message or not.The whole point of caching proxies is to take the load off the origins, meaning their audiences are typically wide and MACs are useless on scopes wider than individual connections, meaning there's nothing to cache there.And nobody's suggesting that this should be the default. @vftdan merely points out that there doesn't seem to be a widely used standard for it even in cases that call for it, such as software distribution.
       
 (DIR) Post #AiY5DFJ3x9XzwbiDce by lyyn@mastodon.ml
       2024-06-03T11:13:46Z
       
       0 likes, 0 repeats
       
       @dside @vftdanIt's just strange for me that this suggestion and the W3 draft have completely different goals (we want caching, the draft wants non-repudiation). But it seems that by offering a public service, even if with repudiability, it becomes kind of non-repudiable, because for example the court can do the same repudiable request-reply and get the confidence that it's exactly what is distributed.
       
 (DIR) Post #AiY6hQZeizZbX2QfQW by lyyn@mastodon.ml
       2024-06-03T11:30:26Z
       
       0 likes, 0 repeats
       
       @dside @vftdan > The whole point of a signature is for its generation to be impossible for anyone but the signer. Meaning non-repudiation is baked into signatures *by definition*. Full stop.While this is true, actually, with signatures you can get repudiability. For example you can update the signing key every day, and release the private part of the keys, for example, after one week of last using it. This way you give people 7 days to update the key they trust. This also allows caching (with updates of the signature and the cache every day).
       
 (DIR) Post #AiY6xmJleLMhbOnIRM by dside@mastodon.ml
       2024-06-03T11:33:23Z
       
       0 likes, 0 repeats
       
       @lyyn not just caching, but by non-authoritative proxies as well — because there may be more of those or because trusted ones for the resource in question might be gone.Meaning those resources have to somehow be authenticated against credentials of the origin without necessarily contacting it. That means that the resource has to be non-repudiable.The difficult part of this interaction is obtaining the public key to validate signatures against. You either have to contact the trusted origin of the key or rely on witnesses (e. g. through their cross-signatures of the supposed public key of the origin).@vftdan
       
 (DIR) Post #AiY7EVxfiQS5nSRJ6u by lyyn@mastodon.ml
       2024-06-03T11:36:26Z
       
       0 likes, 0 repeats
       
       @dside @vftdan > The difficult part of this interaction is obtaining the public key to validate signatures against.Yes, but it is an unrelated problem, with it's own set of unrelated solutions, like PKI, Web of Trust, or just pre-trusted keys like in case of linux distributions' package managers.
       
 (DIR) Post #AiY8NQPfoUsR9JLk4e by dside@mastodon.ml
       2024-06-03T11:49:11Z
       
       0 likes, 0 repeats
       
       @lyyn so you gain repudiation by making old signatures stop being signatures. :blobcatgooglyshrug:@vftdan
       
 (DIR) Post #AiY8TeLmuL7i72V5bk by lyyn@mastodon.ml
       2024-06-03T11:50:21Z
       
       0 likes, 0 repeats
       
       @dside @vftdan Yes, but they are still valid for some configurable time. So you can balance repudiation with frequency of updating caches.
       
 (DIR) Post #AiY9Ja6BxZupz7y6LY by dside@mastodon.ml
       2024-06-03T11:59:45Z
       
       0 likes, 0 repeats
       
       @lyyn and during that time they're non-repudiable. So if someone were to capture additional evidence that this payload was captured at that time and not later non-repudiation can persist.I don't think I'd be comfortable using that 😕@vftdan