RELEASE TODO

[aaronkaplan]

• I'd recommend setting the scene in the very first paragraph,
  e.g. saying that this report is deliberately taking an
  "outside" or "skeptical" view as that's a good process for
  finding issues.
• 6.1.1 - the text still refers to using a DoH server in various
  places - that can be a Do53 server, so better to just say
  recursive
• 6.1.2 - just to be clear - Cloudflare don't, and afaik won't,
  use wkech - in almost all cases they host the authoritative for
  the inner-SNI, so ECH key updates is a purely internal matter for
  them; in cases where they aren't hosting the zone they may
  provide some proprietary API, but I don't know details of that.
  So we can't assume wkech will be used, but if/when it is, it's
  good that this report analyses the potential weaknesses.
• 6.3 bullet 3 - our ZF implementation doesn't need to know about
  zone files directly, it uses bind's nsupdate so only needs to
  know the names and value of the RRs to update, which is a bit
  easier, and there's no realistic chance of updating the wrong
  zone via ZF misconfiguration.
• 7.6.1: such f/w issues are why wkech uses polling from the ZF
  of the CFS, which will almost certainly be allowed
• 9.1.1: I'm also leery of the deletion thing myself and agree it
  could be a footgun
• 9.1.1: I'm not sure pinning to the TLS server cert would help
  much (it'd add another way to break), but pinning to the CA,
  e.g. via CAA, is worth considering for sure - the ZF may well be
  authoritative for the CAA RR for the zone too, in which case it'd
  be a good additional check. I've created an issue for that:
  For ZF, consider pinning to the CA (e.g. via CAA) when checking .well-known content tlswg/wkesni#44
  section 10: this isn't quite right: "Consequently, the usage of
  ECH can be silently thwarted if an attacker holds sway over any
  part of the network path between the user and the intended
  target." An attacker that controls the n/w between recursive and
  authoritative can do the attack, and that part of the n/w might
  not be between the client and intended target.
• 14: the reference at the end of the 2nd para seems
  broken/missing
• 14.1: afaik, Russia still only blocks Cloudflare's ECH and no
  other, so the text is a bit misleading
• 16: bullet list seems malformed