This is a discussion on Re: conjoining dns-forgery-resilience with dns-0x20; also, rtt banding - DNS ; > From: Robert Elz > > From: Paul Vixie > > | 0x20 only contains one protocol change. > | i don't think it's controversial, or > > You mean the protocol change? That is, requiring unchanged question > section ...
> From: Robert Elz
> From: Paul Vixie
> | 0x20 only contains one protocol change.
> | i don't think it's controversial, or
> You mean the protocol change? That is, requiring unchanged question
> section in the reply?
> That's fine, it's what I always kind of assumed was required anyway.
that's good news. anybody else got a contrary opinion? ed suggested making
that one bit of text into its own draft and progressing it directly. anybody
opposed to that?
> But the way you're proposing on using that? While it is very clever, even
> cute, it is also downright evil. The a==A stuff that's in the DNS is truly
> annoying, it should never have been done (though I understand why it was),
> and it would be nice to be able to make it go away at some far distant
> future point of time.
> Doing this case flipping trick, and actually having implementations use it
> in the wild would mean we could never rid ourselves of that botch to the
there's no way to make this go away, ever, except with a new label type, whose
definition will/would presumably be made to preclude this kind of evilness.
> Further, this trick doesn't help at all for the single most important DNS
> lookup that's ever done - the query for the root nameservers. Manage to
> forge a reply to that one and none of the others matter. If anything, by
> making others harder to forge replies for, but leaving this one untouched,
> you'd be shifting attacks more in that direction, which I don't think would
> be a useful result.
of course. likewise hp.com is less secure than dec.com and so on. bad idea,
bad design. except that it's better than nothing. to get actual security we
should deploy Secure DNS aka DNSSEC. especially we should sign the root zone
and distribute the key widely.
> Last, it results in just plain ugly replies - in the context of AXFR I saw
> some mention of name case preservation, and how label compression can make a
> mess of this. I think it was marka who said that it's only in the context
> of AXFR that anyone ever complains about this. I beg to differ - this bugs
> me no end on ordinary queries, and you're proposing making it worse...
since we seem to agree that copying the question is what everybody does and
what everybody should keep doing and what should be clarified in the spec,
then you appear to be arguing that responses ought not use this copied
question as a compression pointer target. sounds fine to me, if i'm reading
you correctly. perhaps an "unless it would lead to truncation that would not
occur if the question section copied from the query were available as a
compression pointer target" exemption, though in an increasingly EDNS0 world
i'm not sure we need to worry much about this as much.
if we uptake ed's suggestion (progress the responder-must-copy clarification
separately) then perhaps that draft would be a good place to recommend the
no-question-pointers logic as well. (trying to conserver RFC numbers here.)
> Please put this trick in the "look ma, no hands" category - treat it as
> something to marvel at, laugh at, and avoid like the plague.
we can't. i'm already marvelling, i'm already laughing, but i'm not avoiding,
and my lack of avoidance is completely within the spec. if a dns initiator
implementor can improve security with this trick, and remain within spec, you
can expect that some, if not many or all, will do so. as a practical matter,
this cat was never in any bag. there's no basis on which to forbid this, nor
any enforcement powers.
further, and this is the part i brought up in the philly meeting yesterday, we
just got our asses handed to us by amit klein, wrt PRNG state prediction. how
many more times would we like this kind of thing to happen? should we wait
until the next round of PRNG predictability attacks are described, before we
decide whether and how to improve transaction level unpredictability? waiting
for DNSSEC means waiting for the U S Government to decide whether to sign the
root and who should hold the key. maybe that's tomorrow, maybe it's in 2012.
we have a tuple
. bernstein showed us how
and why to randomize reqport. klein and many others have showed us how and
why to randomize qid. rtt banding is one way to randomize the respaddr. more
than one upstream-facing reqaddr may be required at some point, chosen at
random. the 0x20 bletcherous seething hack from hell randomizes the qname.
having just been through another qid scare, and not knowing when to expect
DNSSEC for root and .COM (assuming we decide what has to be done about the CD
bit, and that we deploy MSJ's key rollover, and NSEC3 proves to be deployable,
and assuming USG sets ICANN free next year, and assuming ICANN uses its new
freedom to sign the root zone, and assuming verisign can make a business case
for signing .COM, and so on)... i want to see every randomizable element of
tuple actually get randomized.
> ps: a better thing to be spending time on might be to redefine the DNS
> packet format, and fix lots of the issues that we currently have that are
> caused by this - I suspect it can be done in a way (kind of like EDNS0)
> whereby the query format would appear compatible with basic old DNS, but
> would signal advanced capability - once that's done, the reply can be
> whatever will work best - this could fix multiple queries in one packet, add
> as many ID bits as could ever be useful, and whatever else needs doing.
i'm not reading that kind of ambition among the audience at this stage. there
may be a later stage, but right now i predict that we'll fight, mostly, as we
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.