Re: [dns-privacy] Registry framework for draft-ietf-dprive-early-data
On Fri, Jul 31, 2020 at 10:32:17PM +0200, Peter van Dijk wrote: > On Thu, 2020-07-23 at 12:57 +0100, alessan...@ghedini.me wrote: > > Are you saying we shouldn't have a list of allowed RR types at all and just > > limiting to QUERY messages is enough? I asked this question at the last > > meeting > > and the responses were mixed. > > Looking at the list of types, I can't even guess why these types would > be safe and others would not be. If you're going to have a list, it > would be good to explain why those types are on it and the rest is not. You still need an explanation even if there's not a specific list (vs. just "all types are allowed"). An application profile allowing the use of TLS 0-RTT data needs to identify which messages are safe to use with 0-RTT and I'm quite willing to put up a Discuss point if such guidance is not backed by compelling reasoning. -Ben ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Registry framework for draft-ietf-dprive-early-data
On Thu, 2020-07-30 at 02:58 +0100, Tony Finch wrote: > Ilari Liusvaara wrote: > > Then there is RRSIG, which seems bit alarming. While direct queries > > should not do anything special, I noticed two troublesome properties: > > > > 1) The answers can be pretty large (amplification hazard with UDP). > > 2) The queries can be really slow compared to other types. > > Yes. From an implementation perspective, RRSIG queries work in a very > similar way to ANY queries. They have the advantage that no-one is likely > to think an RRSIG query is useful, so it's reasonable to NOTIMP them. > If QTYPE=ANY is forbidden for early data then QTYPE=RRSIG should be too. NOTIMP tells the client 'I do not support the QUERY opcode'. That is not a message you want to send out, unless you want people to just stop querying you. (PowerDNS has picked REFUSED as the response to RRSIG queries). Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Registry framework for draft-ietf-dprive-early-data
Ilari Liusvaara wrote: > > Then there is RRSIG, which seems bit alarming. While direct queries > should not do anything special, I noticed two troublesome properties: > > 1) The answers can be pretty large (amplification hazard with UDP). > 2) The queries can be really slow compared to other types. Yes. From an implementation perspective, RRSIG queries work in a very similar way to ANY queries. They have the advantage that no-one is likely to think an RRSIG query is useful, so it's reasonable to NOTIMP them. If QTYPE=ANY is forbidden for early data then QTYPE=RRSIG should be too. Tony. -- f.anthony.n.finchhttp://dotat.at/ Plymouth: Variable 4 or less, becoming east 3 to 5 for a time. Smooth or slight becoming slight or moderate. Fair. Good. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Registry framework for draft-ietf-dprive-early-data
On Thu, Jul 23, 2020 at 12:57:02PM +0100, alessan...@ghedini.me wrote: > On Wed, Jul 22, 2020 at 10:26:52PM +0300, Ilari Liusvaara wrote: > > On Wed, Jul 22, 2020 at 12:00:43PM -0400, Brian Haberman wrote: > > > Hi all, > > > I have a proposal for the working group that I would like some > > > feedback on. https://tools.ietf.org/html/draft-ietf-dprive-early-data-00 > > > calls out the need for an IANA registry to track which RR Types are > > > allowed to be carried as early data during the TLS session establishment > > > process. Rather than creating yet another IANA registry, I propose that > > > we add a column to the current RR Type registry that indicates whether > > > the RR Type is allowed as early data. For reference... > > > > > > https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4 > > > > > > Thoughts on this? > > > > I think this is a Bad Idea. > > > > The fact that RRTYPE is data RRtype (1-127, 256-61439) already > > establishes it is safe to send as QTYPE in QUERY. Having any unsafe > > things there would already cause major security issues, as DNS > > specifications are very clear that servers MUST NOT refuse > > requests by data QTYPE. Yes, some data TYPEs are special (especially > > NS, CNAME and some DNSSEC stuff), but it is still requirement to not > > have any harmful effects. > > > > However, this does not make any of them safe, only that none is > > specially unsafe. With recursives, bad things happen if network > > attacker can replay 0-RTT data after cache expiry. At worst, this can > > completely compromise the query contents. It looks that one could > > check the ticket age with fairly tight tolerances (failing is only > > one (likely fast) extra RTT) to prevent this from happening. > > Are you saying we shouldn't have a list of allowed RR types at all and just > limiting to QUERY messages is enough? I asked this question at the last > meeting > and the responses were mixed. I was thinking QUERY messges with data TYPE and data CLASS. Which is subset of QUERY messages. Looking at the minutes, I see mention of needing to be idempotent. Actually, I think one wants a stronger property that is analogous to "safe" in HTTP. And I think all data QUERY are meant to satisfy that stronger property. More specifically, "safe" roughly means "no state change", while "idempotent" roughly means "indepdent of order". And when it comes to problematic behavior, I do not expect the esoteric types to be the problem, I expect problems to lie in the well-known types. This is because unless authoritative or recursive server specifically supports some TYPE, it treats it as plain data. And there are limited oppurtunities for anything to go wrong with that. And esoteric types are unlikely to be specially supported. Furthermore, DNS pretty strongly constrains what recursives can do. And the types that worry me the most for potential of special handling are A and . There are CDNs, which definitely do some very special stuff with A and records. Then I have seen some servers that do special things with TXT records. None of these behaviors is anything really dangerous (as that would be a major security issue), but could leak data if requests are replayed. Then there is RRSIG, which seems bit alarming. While direct queries should not do anything special, I noticed two troublesome properties: 1) The answers can be pretty large (amplification hazard with UDP). 2) The queries can be really slow compared to other types. I don't think anything legimately uses direct RRSIG queries. DNSSEC sends partial RRSIG answers as needed (AFAIK, this is the only case where DNS data rrsets are not atomic). And when it comes to early data profiles, I think most define specicial error code meaning "not allowed in early data, try again" (e.g., HTTP 425 status), instead of using generic parse error. New error code in DNS would need EDNS tho (which should not be that problematic requirement). > I'm not against removing the list btw, though I guess it would be helpful to > hear from people who disagree on why they disagree. Yes, I would very much like to hear if there are any more unpleasant surprises lurking here. > > However, there is a potential source of unsafety even in QUERY > > with data QTYPE: EDNS extensions. The base EDNS is safe and essential. > > However, EDNS extensions can do who knows what, and some of them might > > be very much not safe. However, there are some that seem useful. > > > > On useful end, there are various DNSSEC advertisment extensions (e.g., > > ??U and edns-key-tag). As well as Extended DNS Error. On dubious end > > there are things like LLQ and UL (and potentially other stuff as well). > > I guess we can add some text on EDNS to the draft as well. I suspect coming up with what is useful and what is dubious would actually need looking at what the various EDNS extensions do. Allow all or deny all is not likely to be right thing to do.
Re: [dns-privacy] Registry framework for draft-ietf-dprive-early-data
On Wed, Jul 22, 2020 at 12:00:43PM -0400, Brian Haberman wrote: > Hi all, > I have a proposal for the working group that I would like some > feedback on. https://tools.ietf.org/html/draft-ietf-dprive-early-data-00 > calls out the need for an IANA registry to track which RR Types are > allowed to be carried as early data during the TLS session establishment > process. Rather than creating yet another IANA registry, I propose that > we add a column to the current RR Type registry that indicates whether > the RR Type is allowed as early data. For reference... > > https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4 > > Thoughts on this? I think this is a Bad Idea. The fact that RRTYPE is data RRtype (1-127, 256-61439) already establishes it is safe to send as QTYPE in QUERY. Having any unsafe things there would already cause major security issues, as DNS specifications are very clear that servers MUST NOT refuse requests by data QTYPE. Yes, some data TYPEs are special (especially NS, CNAME and some DNSSEC stuff), but it is still requirement to not have any harmful effects. However, this does not make any of them safe, only that none is specially unsafe. With recursives, bad things happen if network attacker can replay 0-RTT data after cache expiry. At worst, this can completely compromise the query contents. It looks that one could check the ticket age with fairly tight tolerances (failing is only one (likely fast) extra RTT) to prevent this from happening. Types that are not data RRtypes might be more mixed bag. Those may have side effects, and also contains the infamous TYPE *. The reason that TYPE is infamous is that its semantics are not quite sensible, and especially that it tends to cause large answers. Then there are CLASSes. The data CLASSes (1-127 and 32768-57343) need to be safe. The other defined classes are NONE and *, which have no sensible semantics in QUERY. Also unlike unknown TYPEs, unkown CLASSes can be refused (REFUSED is sensible for authoritative, and NXDOMAIN for recursive). However, there is a potential source of unsafety even in QUERY with data QTYPE: EDNS extensions. The base EDNS is safe and essential. However, EDNS extensions can do who knows what, and some of them might be very much not safe. However, there are some that seem useful. On useful end, there are various DNSSEC advertisment extensions (e.g., ??U and edns-key-tag). As well as Extended DNS Error. On dubious end there are things like LLQ and UL (and potentially other stuff as well). -Ilari ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] Registry framework for draft-ietf-dprive-early-data
Hi all, I have a proposal for the working group that I would like some feedback on. https://tools.ietf.org/html/draft-ietf-dprive-early-data-00 calls out the need for an IANA registry to track which RR Types are allowed to be carried as early data during the TLS session establishment process. Rather than creating yet another IANA registry, I propose that we add a column to the current RR Type registry that indicates whether the RR Type is allowed as early data. For reference... https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4 Thoughts on this? Regards, Brian signature.asc Description: OpenPGP digital signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
