On Sat, Nov 2, 2019 at 11:52 AM Stephen Farrell <[email protected]> wrote:
> > Hiya, > > On 02/11/2019 18:33, Eric Rescorla wrote: > > On Sat, Nov 2, 2019 at 7:03 AM Paul Hoffman <[email protected]> > wrote: > > > >> On 11/2/19 9:58 AM, Eric Rescorla wrote: > >>> Generally, I would expect that a solution which addressed the active > >> threat model would also address the passive one. > >> > >> Of course, but there are many threat models that have different > solutions. > >> The passive threat models might be addressable more quickly than the > active > >> threat model. > >> > > > > Yes, that's why I asked the question of whether we are trying to solve > the > > active attacker case. > > Tackling passive and active attacks are not mutually > exclusive goals. > Nor did I say they were. > Experience from SMTP/TLS (as I interpret it anyway) > was that defence against active attacks only really > became tractable a few years after mitigations against > passive attacks had been deployed and clearly hadn't > broken anything. Note that that transition did not require any changes > to SMTP/TLS, though it may have needed > the mail equivalent of HSTS and reporting to have been > defined (it's hard to tell what really motivated folks > to try mitigate active attacks for sure). > > Whether or not adot is sufficiently similar is (for me) > an unknown at this point but I'd hope we don't rule that > out. > I think the primary difference between this case and the TLS case, where, as I note below, defense against active attacks was required from the beginning, is the question of whether or not the reference that the initiator has tells it that it supposed to expect security. In the case of TLS you have that with the different URI scheme (https) but in the case of email you do not. Conversely, what made opportunistic style approaches viable for SMTP was that there was an existing protocol handshake that could be conveniently adopted to have upward negotiation (STARTTLS). This was more of a pain with HTTP, though RFC 2817 does in fact specify something. In this case, I think the relevant question is whether there is some viable mechanism (by which I mean one that people might actually use) by which recursive resolvers would, in talking to an authoritative resolver, detect that that resolver supported secure transport and upgrade. If there is, then it's potentially possible to have some kind of opportunistic approach. And conversely, whether it's viable to have the records that point you to the next authoritative convey that you should expect security. If there is, then it's potentially possible/better to have a non-opportunistic approach > ISTM that requiring day-1 defence against active attacks was to an > extent responsible for the lack of deployment > of IPsec and DNSSEC, I don't understand what DNSSEC would do if not defend against active attack. so I hope we keep an eye on that > ball too. > OTOH, TLS had day one defense against active attacks. -Ekr
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
