On Sun, 24 May 2020, Peter van Dijk wrote:
On Sun, 2020-05-24 at 13:43 -0400, Paul Wouters wrote:
But I also don't see the gains of abusing DNSKEY, because you already
need to query the DNSKEY of the domain to get the pesudeo-DNSKEY key,
and then you already lost your privacy.
The draft says 'The pseudo DNSKEY record MUST NOT be present in the
zone.' What can we add to the text to make it clear that no query is
sent to the zone's name servers -until- their TLS key has been
verified?
You confused me with "pseudo DNSKEY record". You meant to say "pseudo DS
record". Now it makes more sense that our suggestions are a lot more
similar then I originally understood.
The draft currently has:
The pseudo DNSKEY record MUST contain Base64 encoded [...]
The pseudo DNSKEY record MUST NOT be present in the zone.
Also, instead of showing openssl commands, explain to the reader the
process of the resolver. What does it fetch, when does it fetch it, what
information is extracted and used.
Your draft also state:
The pseudo DNSKEY type can be used in CDNSKEY and CDS (as defined in
[RFC7344]) records. These records MAY be present in the zone.
I think that should be a MUST, not a MAY. Or else a rogue parent
inserting DS records to MITM the TLS cannot be detected.
Conveying that you can do DoT using DS can only really be done by
overloading the record type.
Which field do you mean by 'the record type'? We chose the algorithm
field for it.
I meant key tag. We have seen issues in the past with both resolver
behaviour with unknown algorithms and registries limiting their drop
down menus for DS components to only valid algorithms.
I thought using keytag 0, which cannot happen normally, would allow
you to leave algorithm and other values more real.
If we don't want to hard fail, then I think we should just
drop this draft and use opportunistic.
This draft, that signals and key-pins, with hard failure, would not
prevent an opportunistic draft/RFC to also exist.
Once the document gets further along, a Security Considerations section
is needed to explain the details of pinning and how it interacts with
TLS level pinning.
If we want to offer hard fail,
then some draft is still useful.
Why not this draft then? :)
Now I understand data is in the DS record, perhaps it can. It does all
depend on whether we want to add limiting on/off signaling in the DS
record only, or if we really want to stuff TLS public keys into the DS.
I'm still not convinced of the latter, but might be persuaded.
I would use the keytag record set to 0 to mean this DS record is not
a real DNSKEY but "something else".
This will require changes in registry software all over the world, or
some hack . I'm not saying that's prohibitive, but our draft is the way
it is because this is one of the many hurdles we wanted to avoid.
A similar problem will happen for new algorithms.
Also, as Petr pointed out, our DNSKEY/DS-based proposal does not
involve additional queries and thus roundtrips; as far as I can
imagine, anything using TLSA would need extra queries.
I don't believe a working solution cannot be allowed to introduce an
extra roundtrip.
I also do not believe that, but it's nice that we can do without the
extra roundtrip anyway!
I'd really like to get the security and threat model cleared up before
making decisions about 1 RTT. For instance, protection against a rogue
parent is not something the draft currently tries to protect against.
Paul
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
