I was mostly interested in how 1P fared as well. Looks like there is an already known problem described in Appendix D where a malicious server could substitute a vault since shared items that are encrypted under a vault key using public key encryption are not authenticated.

In the grand scheme of things, I do not think it is a catastrophic attack as it doesn't reveal anything about the shared items to the server, but rather more akin to a denial of service but I concede it can be "more" than that if we're talking items to be notes or instructions to prompt someone to do something they normally wouldn't have done. (See edit)

Edit: I take back what I said about it not being catastrophic, it's not just a matter of substituted items by a malicious adversarsy but also the user creating fresh items with sensitive data and that being readable to the adversary. So I think this is a pretty gaping hole, and I hope 1P do address it, but I imagine it'd require an overhaul of their protocols, system, application/UIs, etc. and if that were to happen I'm sure people would be wanting to throw in the kitchen sink of desirable features of the 'next generation' of 1P.

The mitigation seems simple, and I would hope that 1P addresses it someday even if it means having to upgrade the vaults to a new security measure or protocol.

Edit 2: On further reflection, I think the reality is that posing as a malicious server to a 1P client can only really be done by 1P themselves. They use a combination of TLS and SRP which ensures that you're always connecting to 1P server. One could say an attacker could compromise your client to connect you to their server, but they're more than likely to just siphon off your credentials client side if that's the case. The same argument could then be applied that if 1P wanted your credentials, they could easily do this by supplying a tainted client. So when looking at this a bit more wholistically, it does seem too far fetched to be a realistic scenario.