>>> Sorry, I realized when i hit "send" that I phrased my previous >>> message >>> poorly. When I say "potential" I mean someone actually presenting a >>> PoC >>> and a CVE is issued for it. Have we seen any of those? > In 2014 a group at UC Berkeley used HTTPS traffic analysis to identify: > > "individual pages in the same web-site with 90% accuracy, exposing > personal details including medical conditions, financial and legal > affairs and sexual orientation." > > They used machine learning to help and that was over 10 years ago. So I > suspect modern day machine learning would make this even easier to do > today. > > Obviously that is HTTP traffic, which is different to the NVMe-TCP > traffic this series is targeting, but it does still seem like a real > concern. > > They talk about a range of defences in the paper, with tradeoffs > between all of them. But the linear defence seems like the one that is > applicable here: > > "linear defense pads all packet sizes up to multiples of 128" > > The linear defence seems to reduce the Pan attack from 60% to around > 25% and the BoG attack from 90% to around 60%. > > On top of that the > > "Burst defense offers greater protection, operating between the TCP > layer and application layer to pad contiguous bursts of traffic up to > predefined thresholds uniquely determined for each website" > > Which to me sounds like the random padding proposed in this series > would provide more protection then the basic linear padding used in the > paper. > > To me analysing TLS traffic does seem like a plausible threat and > something that randomised padding would help with. Leaving it up to > userspace to decide based on their threat model seems like a good > approach as well. > > 1: https://secml.cs.berkeley.edu/pets2014/ > > Alistair
gentle ping. Are there any further thoughts on adding this support? Wilfred
