Hi Simon - thanks for the response. Please find my reply inline below: On Wed, 31 May 2023 at 11:07, Simon Richter <s...@debian.org> wrote: > > On 5/31/23 05:42, James Addison wrote: > > > * It allows other devices on the local network segment to inspect the > > content that other nodes are sending and receiving. > > That is very theoretical: > > - when you use switches, the local network segment has no other nodes > - if there were other nodes, they would likely miss some packets in > the conversation, which means they cannot generate checksums > - there is no software that can perform this inspection
Yep, there are limitations to work within, and the result would be the groundwork for some kind of 'integrity appliance', either within the local network or deliberately outside of it. An alternative (that may already exist, I would be surprised if not) would be to run two-or-more instances of the same computing hardware with key I/O interfaces between all of them. > > * As another thread participant mentioned, if you don't trust a global > > passive adversary, then it may be sensible to question whether you can > > trust their certificate issuers (I admit that your HPKP comments > > partially > > address this concern). If you don't trust either, you might choose to > > save > > some CPU cycles (both for yourself and those who may be gathering your > > data). > > The reason we're even having this debate is that the use of TLS is of > little consequence from an integrity point of view, because we're doing > our own verification with our own PKI that is independent from TLS > certificate issuers, and that isn't going to change. > > Because the use of TLS is inconsequential, it is a trade-off between > various weak reasons: > > 1. unencrypted HTTP can be cached with a caching proxy > 2. unencrypted HTTP can be redirected to a local mirror > 3. encrypted HTTPS does not let a listener determine quite as easily > what software you are running on your machine > 4. encrypted HTTPS requires CA certificates to be deployed to clients > and marked as trusted, or apt will fail. Thanks for articulating these much more clearly than I did. I think it's fine if we're making a change that is broadly agreed upon; I wasn't able to find a decision that would be suitable to link to from the documentation (or commit log) when searching the mailing lists earlier, and since it's debatably-meritable change with potential impact on users and infrastructure (albeit in a gradual way) I wanted to raise some awareness and also check where the reasoning for the change originates. Thanks, James
