Hi Paul
On Thu, Dec 13, 2018 at 09:11:52PM +0000, Paul Hoffman wrote:
> There are many ways to get a key and then compare the hash of the key with
> the hash you get securely from the DNS.
>
> > If it can be
> > demonstrated to work for near-future algorithms (next 2-3 decades), then
> > it's fine.
>
> SHA-256 is not near-future: it has been deployed for well over a decade.
Did you really mean to say this, to tell me that SHA-256 is deployed? It
seems belittling rather than address what's being discussed.
The "near-future" remark (and the whole topic) was for post-quantum
crypto algorithms such as the ones in the NIST competition. Some of
these seem to have rather large key sizes, so the RDATA of an NS record
will not be sufficiently long to hold key material. Perhaps it can hold
a digest, and then there has to be some other way to fetch a key.
> > It is over 13 years since RFC 4035 and DNSSEC is still not in widespread
> > use. Features take time to be adopted and so if the proposed protocol
> > will need revision to make it support another algorithm, then it'll take
> > as many years from that time to be available, so we should future proof
> > it a bit.
>
> 256-bit hashes do not need to be "future proof": they are
> well-established. 256-bit keys do not need to be "future proof"
> either.
The discussion is not about specific schemes like hashes or keys or
256-bits.
> >>> 4. NS records returned as part of delegations are unsigned, so for a
> >>> resolver to trust key information in the RDATA of such NS records in a
> >>> delegation, it would require the delegation to be returned using secure
> >>> transport to the parent-side nameserver of the zone cut. During last
> >>> night's conversation, there was some talk about fallback to plain
> >>> transports - it will not be useful unless the entire delegation from
> >>> root is followed with secure transports.
> >>
> >> I agree with you that there is a security gap here, as with most steps
> >> of indirection.
> >>
> >> But i'd temper the "will not be useful" a little bit -- maybe "will not
> >> defend against active attackers on first connection" is more accurate?
> >>
> >> At any rate, the NS record could itself be DNSSEC-signed, and a
> >> suitably-cautious client could ask the server for its own NS record and
> >> associated RRSIG (QNAME-minimized, of course) before asking for anything
> >> else.
> >
> > Maybe.. I am just pointing out the issues. Perhaps there's some benefit
> > in signing them and the address glue anyway, to stop resolvers from
> > going off on wild chases due to some kinds of poisoning.
>
> NS records are signed; is is only the glue records that are not. The
> names being discussed here are in the NS records themselves.
NS records in a delegation are not signed. If you want authoritative
signed NS records, you have to find them at the apex of the child
zone. But how would you contact the child zone's nameservers and ask it
for the signed NS at the zone's apex if you don't know how to make a
secure path to it?
Mukund
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
