Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective
Paul Hoffman wrote: > > If I have a path with authentication and a path without, and I prefer > (not demand) the path with authentication, I am taking advantage of it. Right, but is the authenticated path securely authenticated? i.e. can the client tell that an attacker is monkeying around with the authenticated path? This is important because it allows clients to make a meaningful choice between security and availabilty, while still being opportunistic (i.e. zero per-server config on the client). If the client can't tell the difference between no authenticated channel and an attacked authenticated channel, it has no meaningful choice other than to fall back to unauthenticated encryption, and the upshot is that the authenticated channel doesn't actually provide any security improvement, and the only option clients have is unauthenticated encryption. > > For protocols like SMTP or DNS there isn't an easy identifier that can > > be reliably authenticated, > > Why not? IP addresses work just fine in both of those cases. No, for SMTP the relevant identifier is the domain in the recipient email address. When we started working on DANE the problems were that (1) the MX target name often doesn't match the server's idea of its own name (2) the server's certificate often doesn't match either name Auth DNS has problem (1) (but not 2 because there's no encryption yet), and also has the problem that it's more latency sensitive and doesn't have a fast way to signal that encryption is available. For authentication to actually be secure, there has to be a signal (e.g. DANE) that this server has been configured without name mismatches, so the client can properly authenticate it. Tony. -- f.anthony.n.finchhttp://dotat.at/ Sole, Lundy, Fastnet, Irish Sea: Variable 4, becoming south or southwest 4 or 5, occasionally 6 in Irish Sea. Slight or moderate. Occasional drizzle, fog patches at first. Moderate or good, occasionally very poor at first. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective
Hi All, Thanks Paul and Tony for digging into this. I've been thinking about this from a user perspective, but my desired user perspective behaviour influences the recursive resolver behaviour. As I see it, the problem with downgrade attacks is when the user is unaware of the fact that this is occuring. My user persepctive requirement is that I know which of the following states my DNS queries are being made by the recursive resolver: cleartext, encrypted (but unautheniticated) or encrypted and authenticated. I would like some visual representation of the status, similar to the http/https visualisation in modern web browsers. But, that is a client side implementation choice. To do it though, we need to know what the status is. Thus, I am proposing that this information is included in the client (stub) to recursive resolver protocol. Could EDNS be used to do this? With this information available, one can do opportunistic encryption and/or authentication and not require downgrade attack prevention but push that risk to the end user. This may be unwise, but I leave that the community's wisdom. Regards, Hugo Connery On Tue, 2018-10-02 at 19:57 +, Paul Hoffman wrote: > On Oct 2, 2018, at 11:26 AM, Tony Finch wrote: > > > > Paul Hoffman wrote: > > > On Oct 2, 2018, at 3:12 AM, Tony Finch wrote: > > > > Paul Hoffman wrote: > > > > > > > > > > I do not have a scenario where the client (the resolver in > > > > > this case) > > > > > needs downgrade protection for privacy. > > > > > > > > In that case there's no need to worry about authentication at > > > > all. > > > > (But I disagree.) > > > > > > And I disagree that there is "no need to worry". As I said in my > > > initial > > > message, a resolver operator might want to take advantage of it > > > if it is > > > available. > > > > I don't understand: first you say you don't need downgrade > > protection, > > then you say you want authentication. > > Yes, exactly. > > > This isn't consistent. > > Yes, it is. Note the difference between "need" and "want". > > > You aren't > > taking advantage of authentication if you are vulnerable to a > > downgrade > > attack. > > If I have a path with authentication and a path without, and I prefer > (not demand) the path with authentication, I am taking advantage of > it. > > > In that case the authentication is worthless. > > We disagree. To me (and clearly to many others), it has worth when it > is used. > > > > > > > More generally, I don't think the term "opportunistic" is very > > > > helpful, > > > > > > but it is the hard-fought agreement of the IETF. See RFC > > > 7435. > > > > Yeah, and the point I am making is that it is important to pick > > apart the > > teo options described in RFC 7435's abstract. They have very > > different > > deployment characteristics and security guarantees. For protocols > > like > > SMTP or DNS there isn't an easy identifier that can be reliably > > authenticated, > > Why not? IP addresses work just fine in both of those cases. The web > world has decided that domain names are good enough identifiers for > them, so other worlds might use them as well. > > > so authenticated encryption needs extra deployment work > > (e.g. DANE) to be reliable, > > DANE works as well, but it is not the only possibility, depending on > your use case. If you want to stay within the single-root DNSSEC > model, DANE works great today, and there have already been proposals > here for protocol extensions to make domain names and IP addresses > work as well if we authenticate them on the parent side of a zone > cut. > > > and if you do that work you get downgrade > > protection as a bonus. If you don't do the extra work you can do > > unauthenticated encryption, but you remain vulnerable to active > > attacks. > > If you do the extra work without including downgrade protection > > then you > > might as well not have bothered. > > Again, we disagree. Some resolver operators want to get good security > when they can get it, and are willing to do a little work to get it. > > > Perhaps I should say that this strict security can only apply if > > both the > > server advertises it and the client looks for it; if either of > > those don't > > apply then you get unauthenticated opportunistic encryption, which > > is OK, > > but we can do better when both ends want to be secure. > > Yes, that would be good to say. :-) It then does not denigrate the > people who don't need strict security but want to use what RFC 7435 > describes as opportunistic. > > --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective
On Oct 2, 2018, at 11:26 AM, Tony Finch wrote: > > Paul Hoffman wrote: >> On Oct 2, 2018, at 3:12 AM, Tony Finch wrote: >>> Paul Hoffman wrote: I do not have a scenario where the client (the resolver in this case) needs downgrade protection for privacy. >>> >>> In that case there's no need to worry about authentication at all. >>> (But I disagree.) >> >> And I disagree that there is "no need to worry". As I said in my initial >> message, a resolver operator might want to take advantage of it if it is >> available. > > I don't understand: first you say you don't need downgrade protection, > then you say you want authentication. Yes, exactly. > This isn't consistent. Yes, it is. Note the difference between "need" and "want". > You aren't > taking advantage of authentication if you are vulnerable to a downgrade > attack. If I have a path with authentication and a path without, and I prefer (not demand) the path with authentication, I am taking advantage of it. > In that case the authentication is worthless. We disagree. To me (and clearly to many others), it has worth when it is used. > >>> More generally, I don't think the term "opportunistic" is very helpful, >> >> but it is the hard-fought agreement of the IETF. See RFC 7435. > > Yeah, and the point I am making is that it is important to pick apart the > teo options described in RFC 7435's abstract. They have very different > deployment characteristics and security guarantees. For protocols like > SMTP or DNS there isn't an easy identifier that can be reliably > authenticated, Why not? IP addresses work just fine in both of those cases. The web world has decided that domain names are good enough identifiers for them, so other worlds might use them as well. > so authenticated encryption needs extra deployment work > (e.g. DANE) to be reliable, DANE works as well, but it is not the only possibility, depending on your use case. If you want to stay within the single-root DNSSEC model, DANE works great today, and there have already been proposals here for protocol extensions to make domain names and IP addresses work as well if we authenticate them on the parent side of a zone cut. > and if you do that work you get downgrade > protection as a bonus. If you don't do the extra work you can do > unauthenticated encryption, but you remain vulnerable to active attacks. > If you do the extra work without including downgrade protection then you > might as well not have bothered. Again, we disagree. Some resolver operators want to get good security when they can get it, and are willing to do a little work to get it. > Perhaps I should say that this strict security can only apply if both the > server advertises it and the client looks for it; if either of those don't > apply then you get unauthenticated opportunistic encryption, which is OK, > but we can do better when both ends want to be secure. Yes, that would be good to say. :-) It then does not denigrate the people who don't need strict security but want to use what RFC 7435 describes as opportunistic. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective
Paul Hoffman wrote: > On Oct 2, 2018, at 3:12 AM, Tony Finch wrote: > > Paul Hoffman wrote: > >> > >> I do not have a scenario where the client (the resolver in this case) > >> needs downgrade protection for privacy. > > > > In that case there's no need to worry about authentication at all. > > (But I disagree.) > > And I disagree that there is "no need to worry". As I said in my initial > message, a resolver operator might want to take advantage of it if it is > available. I don't understand: first you say you don't need downgrade protection, then you say you want authentication. This isn't consistent. You aren't taking advantage of authentication if you are vulnerable to a downgrade attack. In that case the authentication is worthless. > > More generally, I don't think the term "opportunistic" is very helpful, > > but it is the hard-fought agreement of the IETF. See RFC 7435. Yeah, and the point I am making is that it is important to pick apart the teo options described in RFC 7435's abstract. They have very different deployment characteristics and security guarantees. For protocols like SMTP or DNS there isn't an easy identifier that can be reliably authenticated, so authenticated encryption needs extra deployment work (e.g. DANE) to be reliable, and if you do that work you get downgrade protection as a bonus. If you don't do the extra work you can do unauthenticated encryption, but you remain vulnerable to active attacks. If you do the extra work without including downgrade protection then you might as well not have bothered. Perhaps I should say that this strict security can only apply if both the server advertises it and the client looks for it; if either of those don't apply then you get unauthenticated opportunistic encryption, which is OK, but we can do better when both ends want to be secure. Tony. -- f.anthony.n.finchhttp://dotat.at/ Biscay: Easterly 5 or 6 in far southwest, otherwise variable 3 or 4. Slight or moderate. Fair. Good. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective
On Oct 2, 2018, at 3:12 AM, Tony Finch wrote: > > Paul Hoffman wrote: >> >> I do not have a scenario where the client (the resolver in this case) >> needs downgrade protection for privacy. > > In that case there's no need to worry about authentication at all. > (But I disagree.) And I disagree that there is "no need to worry". As I said in my initial message, a resolver operator might want to take advantage of it if it is available. > More generally, I don't think the term "opportunistic" is very helpful, but it is the hard-fought agreement of the IETF. See RFC 7435. The abstract is quite simple: This document defines the concept "Opportunistic Security" in the context of communications protocols. Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective
Paul Hoffman wrote: > > I do not have a scenario where the client (the resolver in this case) > needs downgrade protection for privacy. In that case there's no need to worry about authentication at all. (But I disagree.) More generally, I don't think the term "opportunistic" is very helpful, because there are several useful levels: * cleartext * unauthenticated - the client auto-discovers encryption is available, but doesn't have any way to reliably authenticate the server; an attacker can force the client to downgrade to cleartext. * authenticated - there is an explicit signal (e.g. DANE, STS) that the server supports properly authenticated encryption; an attacker can deny service but not force a downgrade to cleartext. * pre-configured The end goal we should be aiming for is as much authenticated encryption as possible, but it's reasonable to allow unuathenticated encryption as an intermediate step. Tony. -- f.anthony.n.finchhttp://dotat.at/ safeguard the balance of nature and the environment ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective
On Oct 1, 2018, at 10:49 AM, Tony Finch wrote: > > Paul Hoffman wrote: >> On Oct 1, 2018, at 8:50 AM, Tony Finch wrote: >>> >>> Paul Hoffman wrote: During earlier discussions of opportunistic encryption in the IETF, attempted-but-not-required authentication was strongly preferred over "don't even attempt to authenticate". >>> >>> This is only worthwhile if there is downgrade protection, i.e. the client >>> needs to be able to tell if it is supposed to be able to rely on an >>> authentication mechanism (e.g. using DANE). Without downgrade protection >>> it's equivalent to encryption without authentication. >> >> We have to be careful when we are talking about recursive resolvers. By >> "client" above, I think you mean "customer of the recursive resolver" >> and not "the side of the recursive resolver talking to authoritative >> servers". > > No, I'm thinking in terms of client = recursive, server = authoritative, > which are the ends of the connection that we want to improve. I do not have a scenario where the client (the resolver in this case) needs downgrade protection for privacy. We have no privacy now. If we start having privacy, there might be resolvers who only want to send queries that are private, but that feels like a different DNS than what we have today. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective
Paul Hoffman wrote: > On Oct 1, 2018, at 8:50 AM, Tony Finch wrote: > > > > Paul Hoffman wrote: > >> > >> During earlier discussions of opportunistic encryption in the IETF, > >> attempted-but-not-required authentication was strongly preferred over > >> "don't even attempt to authenticate". > > > > This is only worthwhile if there is downgrade protection, i.e. the client > > needs to be able to tell if it is supposed to be able to rely on an > > authentication mechanism (e.g. using DANE). Without downgrade protection > > it's equivalent to encryption without authentication. > > We have to be careful when we are talking about recursive resolvers. By > "client" above, I think you mean "customer of the recursive resolver" > and not "the side of the recursive resolver talking to authoritative > servers". No, I'm thinking in terms of client = recursive, server = authoritative, which are the ends of the connection that we want to improve. Tony. -- f.anthony.n.finchhttp://dotat.at/ Hebrides, Bailey, Fair Isle, Faeroes, Southeast Iceland: Variable 3 or 4 at first in east Fair Isle, otherwise cyclonic or westerly 6 to gale 8, increasing severe gale 9 for a time, then decreasing 4 at times later. Moderate or rough, becoming very rough or high for a time. Rain or squally showers. Good, occasionally poor. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective
On Oct 1, 2018, at 8:50 AM, Tony Finch wrote: > > Paul Hoffman wrote: >> >> During earlier discussions of opportunistic encryption in the IETF, >> attempted-but-not-required authentication was strongly preferred over >> "don't even attempt to authenticate". > > This is only worthwhile if there is downgrade protection, i.e. the client > needs to be able to tell if it is supposed to be able to rely on an > authentication mechanism (e.g. using DANE). Without downgrade protection > it's equivalent to encryption without authentication. We have to be careful when we are talking about recursive resolvers. By "client" above, I think you mean "customer of the recursive resolver" and not "the side of the recursive resolver talking to authoritative servers". Brian asked for this thread to be from the perspective of a recursive resolver operator. If I were running a recursive resolver, I want to do the best job I can for my customers, in this case giving them better privacy. I cannot guarantee them great privacy, but I can make good efforts even if they don't understand those efforts, and attempted-but-not-required authentication is better effort than "don't even attempt to authenticate". Personally, I do not know of any resolver customers that require downgrade protection unless they are running the recursive resolver for just themselves. That is, "downgrade protection" means "if you cannot get an authenticated answer, you literally want no answer at all". Answers for some RRtypes, notably TLSA, require DNSSEC authentication that must have downgrade protection, but that is not what we are discussing here. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective
Paul Hoffman wrote: > > During earlier discussions of opportunistic encryption in the IETF, > attempted-but-not-required authentication was strongly preferred over > "don't even attempt to authenticate". This is only worthwhile if there is downgrade protection, i.e. the client needs to be able to tell if it is supposed to be able to rely on an authentication mechanism (e.g. using DANE). Without downgrade protection it's equivalent to encryption without authentication. We discussed this a few weeks ago, thread starting at https://www.ietf.org/mail-archive/web/dns-privacy/current/msg02124.html Tony. -- f.anthony.n.finchhttp://dotat.at/ North Fitzroy, Sole: Variable 4, becoming easterly 4 or 5 in east Sole. Moderate, occasionally rough at first. Fair. Good. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective
On Oct 1, 2018, at 6:36 AM, Brian Haberman wrote: > > All, > Thanks for a productive set of exchanges on the user perspective > last week! I would like the focus for this week (10/1-10/7) to be on > clarifying the requirements from the perspective of the recursive > resolver operator. So far, I have seen: > > * DNS transaction privacy w/o authentication > * DNS transaction privacy w/ authentication of the authoritative server(s) > > Do others have additional requirements? A third one is DNS transaction privacy with attempted-but-not-required authentication. This is the opportunistic encryption scenario: a resolver wants the best transaction privacy they can get. If example.com has two nameservers, ns1.example.com and ns2.example.com, and I cannot authenticate ns1.example.com, I will prefer to use ns2.example.com because doing so make a system-in-the-middle attack harder. I might sometimes try to authenticate with ns1.example.com again so that I can then choose between them based on other attributes such as speed, but I will prioritize ability to authenticate. During earlier discussions of opportunistic encryption in the IETF, attempted-but-not-required authentication was strongly preferred over "don't even attempt to authenticate". --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
