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'm not against removing the list btw, though I guess it would be helpful to hear from people who disagree on why they disagree. > 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). I guess we can add some text on EDNS to the draft as well. Cheers _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
