Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
On Wed, 27 May 2020, Peter van Dijk wrote: DoT authoritatives would need to keep both the old and new certificates on hand during the transition keys, not certificates I would not rule out that people want to run this using a CA chain. Limiting the signaling to EE-certs or pubkeys is not needed. Especially if you use TLSA, it makes no sense to take away that flexibility that some people want, so they can replace their TLS certs and only pin it to one (their own?) CA. , and DoT recursives would need some way to signal in the ClientHello which one they are expecting. I don't follow - if the DS set has both the old and new keys, the DoT recursive will accept either. I ki Only signal the name and mandate TLSA via tls-dnssec-chain, and this is not a problem. Regular TLSA processing applies. This is pretty far from how TLS normally works. Hmm, is TLSA 3 1 x far from how TLS normally works? I feel like I'm missing something. It's a very liited subset of how TLS works :) I considered putting names in DS records; I also considered chain-extension; but I failed to consider them together! With NS names 'verified' by DS, that looks like something that would also be secure. I agree with the problems Petr spotted - I'm aware of roughly zero implementations of dnssec-chain in clients or servers. stubby For me, with 10 domains on two name servers, not having the complexity of chain-extension is preferable. For others, with a million domains, obviously our draft does not scale. I've been assuming we'd end up with two or three separate signals, each fit for purpose for a certain scale. Your proposal seems like a viable candidate to be one of those to me. Not having SBKI in CDS/CDNSKEY's would be much cleaner from a protocol Paul ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
On Wed, 27 May 2020, Petr Špaček wrote: - I don't see any traction for draft-ietf-tls-dnssec-chain-extension. Do you see any evidence it is going to change? The draft has been resubmitted for the ISE stream (not TLS WG) as draft-dukhovni-tls-dnssec-chain Stubby already implements it. We do so traction and a lot of interest. Viktor wants to add support to openssl. But we are unfortunately waiting on the ISE :/ - If I'm not mistaken authoritative servers implementing draft-ietf-tls-dnssec-chain-extension would need to add DNS resolver to refresh chain of records leading to TLSA records under their name: No. An external progam can update the blob and regularly rewrite it. The DNS auth server can pick it up using inotify or something. b) Auth servers nowadays do not even know all their _names_ and do not care/need to know. How would we solve that? Whatever part talks TLS, knows the certificate it is using, and can pull the SAN with FQDN from the certificate. Paul ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
On Wed, 27 May 2020, Ben Schwartz wrote: I agree that the TLS DNSSEC chain extension isn't substantially deployed today, but I don't think that should stop us from using it if it would help. This use case is important enough to drive deployment. If people really want to avoid doing an extra RTT, then I guess this extension could be used. But you would still need to have some kind of TLS server SAN with FQDN conveyed within the DS record. Having a single bit in the DS signifying "yes there is DoT", isn't enough if the additional glue NS records can point to any machine with a valid TLSA chain. Using this extension would indeed require the authoritative server to provide TLSA records for its own name. I don't think it actually has to "resolve its own name", because it can choose a name that is in-bailiwick. Servers can choose an in-bailiwick authentication name even if existing NS records have an out-of-bailiwick name. If an authoritative server has multiple names, it would presumably identify the right one from the TLS-SNI. The nameserver name has to be known (from DS) before the resolver connects to the DoT server. How the DoT server would identify itself, via TLSA or via fake DNSKEY doesn't really matter as it can just provide whatever we decide to use. Personally, I think it would be cleanest if we use the DS to signal the DoT nameserver only by FQDN. Then connect to it and get the TLS chain containing the TLSA record and the CDS that matches the DS. That way, we can avoid adding pseudo-DNSKEY records. I understand not every registry supports DS/CDS, but I think if you want to deploy this, you cannot be depending on humands anything, so CDS or CDNSKEY support would be a requirement anyway. Let's just convince those registries that support CDNSKEY but not CDS, that they need to fix things. It would make everything a LOT cleaner and we got no bogus DNSKEY records to ignore in our DNSSEC validation path. Paul ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
Peter van Dijk wrote: > On Tue, 2020-05-26 at 09:10 +0200, Ondřej Surý wrote: > > > > 1. Bit 7 of the Flags fields needs to be 0. > > Definitely [...] I noted earlier that whatever flags we might need, it's > definitely *not* ZONE and SEP. > > > 2. This needs a new Protocol number > > I understand why you would say that, but I'd love to avoid doing that. > I wonder how much 'IETF' pain specifying another protocol number would > be, but what worries me more, ironically, is how it changes the format > away from normal DNSSEC. The draft was written such that a lot of > existing software needs no changes at all - I don't know if changing > the protocol number is compatible with that goal. This made me wonder if this pseudorecord should be a KEY instead, and then I wondered how hard it would be to persuade existing code to generate a DS from a KEY. But anyway, this signalling and verification scheme sounds clever and neat. Tony. -- f.anthony.n.finchhttp://dotat.at/ Southeast Iceland: Southwesterly 5 to 7 at first in north, otherwise southerly 3 to 5. Moderate or rough, becoming moderate later. Drizzle and fog patches later. Moderate or good, occasionally very poor later.___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
Thanks for the explanations. Having multiple TLS-DS records during TLS key
rolls does seem like a pretty good solution.
There are still some potential operational rough edges here. For example,
an "emergency" certificate replacement (e.g. in event of compromise) is
difficult, because the old fingerprint set might be cached all over the
internet. Cautious authoritative operators might have to set low TTLs,
resulting in slower lookups and increased load on the parent zones.
In my view, the most important link for ADoT is to the TLD, because the
TLD+1 is typically the most sensitive label. In this solution, TLS key
agility seems likely to be particularly difficult for TLD operators,
assuming that updating the root zone is relatively slow.
I agree that the TLS DNSSEC chain extension isn't substantially deployed
today, but I don't think that should stop us from using it if it would
help. This use case is important enough to drive deployment.
Using this extension would indeed require the authoritative server to
provide TLSA records for its own name. I don't think it actually has to
"resolve its own name", because it can choose a name that is in-bailiwick.
Servers can choose an in-bailiwick authentication name even if existing NS
records have an out-of-bailiwick name. If an authoritative server has
multiple names, it would presumably identify the right one from the TLS-SNI.
On Wed, May 27, 2020 at 4:28 AM Peter van Dijk
wrote:
> Hello Ben,
>
> On Tue, 2020-05-26 at 21:27 -0400, Ben Schwartz wrote:
>
> I like the idea of signalling DoT support in the DS record, but I worry a
> bit about putting the SPKI fingerprint in the DS as well. Having to update
> the parent zone whenever the TLSA key needs to be rotated seems cumbersome
> and fragile, especially if the nameserver is operated by a third party.
>
>
> I agree, it's the weakest link in the proposition.
>
> DoT authoritatives would need to keep both the old and new certificates on
> hand during the transition
>
>
> keys, not certificates
>
> , and DoT recursives would need some way to signal in the ClientHello
> which one they are expecting.
>
>
> I don't follow - if the DS set has both the old and new keys, the DoT
> recursive will accept either. I ki
>
> This is pretty far from how TLS normally works.
>
>
> Hmm, is TLSA 3 1 x far from how TLS normally works? I feel like I'm
> missing something.
>
> I wonder if you considered using draft-ietf-tls-dnssec-chain-extension
> instead? That would provide the same security and performance, using less
> volatile information in the parent. Specifically, I think that the DS
> record would have to convey one bit ("DoT enabled") plus the name of the
> nameserver (which should probably match the NS record). That seems
> preferable to me.
>
>
> I considered putting names in DS records; I also considered
> chain-extension; but I failed to consider them together! With NS names
> 'verified' by DS, that looks like something that would also be secure. I
> agree with the problems Petr spotted - I'm aware of roughly zero
> implementations of dnssec-chain in clients or servers.
>
> That seems preferable to me.
>
>
> For me, with 10 domains on two name servers, not having the complexity of
> chain-extension is preferable. For others, with a million domains,
> obviously our draft does not scale. I've been assuming we'd end up with two
> or three separate signals, each fit for purpose for a certain scale. Your
> proposal seems like a viable candidate to be one of those to me.
>
> 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
>
smime.p7s
Description: S/MIME Cryptographic Signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
Hello Ben,
On Tue, 2020-05-26 at 21:27 -0400, Ben Schwartz wrote:
> I like the idea of signalling DoT support in the DS record, but I worry a bit
> about putting the SPKI fingerprint in the DS as well. Having to update the
> parent zone whenever the TLSA key needs to be rotated seems cumbersome and
> fragile, especially if the nameserver is operated by a third party.
I agree, it's the weakest link in the proposition.
> DoT authoritatives would need to keep both the old and new certificates on
> hand during the transition
keys, not certificates
> , and DoT recursives would need some way to signal in the ClientHello which
> one they are expecting.
I don't follow - if the DS set has both the old and new keys, the DoT recursive
will accept either. I ki
> This is pretty far from how TLS normally works.
Hmm, is TLSA 3 1 x far from how TLS normally works? I feel like I'm missing
something.
> I wonder if you considered using draft-ietf-tls-dnssec-chain-extension
> instead? That would provide the same security and performance, using less
> volatile information in the parent. Specifically, I think that the DS record
> would have to convey one bit ("DoT enabled") plus the name of the nameserver
> (which should probably match the NS record). That seems preferable to me.
I considered putting names in DS records; I also considered chain-extension;
but I failed to consider them together! With NS names 'verified' by DS, that
looks like something that would also be secure. I agree with the problems Petr
spotted - I'm aware of roughly zero implementations of dnssec-chain in clients
or servers.
> That seems preferable to me.
For me, with 10 domains on two name servers, not having the complexity of
chain-extension is preferable. For others, with a million domains, obviously
our draft does not scale. I've been assuming we'd end up with two or three
separate signals, each fit for purpose for a certain scale. Your proposal seems
like a viable candidate to be one of those to me.
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] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
On 27. 05. 20 3:27, Ben Schwartz wrote:
> I like the idea of signalling DoT support in the DS record, but I worry a bit
> about putting the SPKI fingerprint in the DS as well. Having to update the
> parent zone whenever the TLSA key needs to be rotated seems cumbersome and
> fragile, especially if the nameserver is operated by a third party. DoT
> authoritatives would need to keep both the old and new certificates on hand
> during the transition, and DoT recursives would need some way to signal in
> the ClientHello which one they are expecting. This is pretty far from how
> TLS normally works.
The proposed mechanism works the other way around:
Zone can have multiple DS records at a time, thus exposing multiple hashes to
resolvers. Rresolver then checks if any of the hashes in DS matches, so the
auth side can be use any cert without prior communication with resolver.
>
> I wonder if you considered using draft-ietf-tls-dnssec-chain-extension
> instead? That would provide the same security and performance, using less
> volatile information in the parent. Specifically, I think that the DS record
> would have to convey one bit ("DoT enabled") plus the name of the nameserver
> (which should probably match the NS record). That seems preferable to me.
I can see three problems, not sure which one is worse:
- I don't see any traction for draft-ietf-tls-dnssec-chain-extension. Do you
see any evidence it is going to change?
- If I'm not mistaken authoritative servers implementing
draft-ietf-tls-dnssec-chain-extension would need to add DNS resolver to refresh
chain of records leading to TLSA records under their name:
a) Having resolver on auth side is major paradigm change in deployment of auth
servers and I'm not convinved auth operators would be happy with it as it adds
additional fragility.
b) Auth servers nowadays do not even know all their _names_ and do not
care/need to know. How would we solve that?
Petr Špaček @ CZ.NIC
>
> On Tue, May 26, 2020 at 5:13 PM Peter van Dijk > wrote:
>
> On Sun, 2020-05-24 at 17:36 -0400, Paul Wouters wrote:
> > I thought using keytag 0, which cannot happen normally, would allow
> > you to leave algorithm and other values more real.
>
> This comment made me curious. Why would that be true? So I generated
> 524726 keys equally split between algorithms 8, 13, and 15.
>
> The result: 2 algo 13 keys with tag 0, 7 algo 15 keys with tag 0. I've
> pasted them at
> https://gist.github.com/Habbie/feb0bf288ea1137bee5a2c3d8913ba7f (happy
> to provide the related private keys if anybody cares).
>
> None for RSA, though, which I bet was predicted in the work behind
>
> https://indico.dns-oarc.net/event/22/contributions/315/attachments/316/555/Quest_for_the_missing_keytags.pdf
> and
>
> https://ripe78.ripe.net/presentations/5-20190520-RIPE-78-DNS-wg-Keytags.pdf
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
