Re: [Ntp] NTS pool support

On 2019-07-22 08:58, Patrik Fältström wrote:
> On 22 Jul 2019, at 8:25, Ask Bjørn Hansen wrote:
> 
>> I know how DNSSEC works, but I failed at explaining my idea well!
> 
> :-)
> 
>>> You must trust whoever is doing the validation. You extrapolate that to you having to do the validation, but that builds upon you not trusting (for example) the access provider that runs the recursive resolver for you also do the validation.
>>
>> Right. I don’t believe trusting the access provider (typically) nearly comes close to the goal of NTS in terms of security.
> 
> Ok, if you do not trust DNS, then I think there are many more attack vectors for NTS anyways, as you can do all different kind of tricks as any CA can issue a certificate for any domain name.
> 

I think this is why Ask proposed a private/"per-pool" CA.

The issue is not (imo) about weather you trust DNS, TLS or carrier
pidgeons. An operator of a pool probably wants to express multiple
properties using different technical representations:

- DNSSEC represents trust in domain ownership and control
- TLS certs issued by a private CA represents trust in certain
properties of the pool (which can be made *explicit* in CA policy)

These are not mutual exclusive nor do they even overlap that much.

	Cheers Leif

>> With “regular NTS” you don’t trust NTS, but rather the chosen TLS infrastructure.  Changing the trust model to rely on DNS doesn’t seem right.
> 
> Well, you must trust a combination of the cloud of CA's in the world where any CA can issue a certificate for any domain name out there (unless you tie it down by placing special resource records in the DNS), OR you use DANE and place your cert in the DNS and trust it there.
> 
> So, we can split hairs what in your sentence is implied by "rely on". I claim we already in NTS as in other things rely quite heavily on DNS to the degree that DNSSEC should always be used. Just like for any use of the Internet.
> 
>> What I meant with the above was that if the client does DNSSEC validation and the pool service does DNSSEC signing you (might?) get the same security guarantees back.
> 
> It's hard to compare and claim "same security".
> 
>> There are a lot more TLS capable clients than DNSSEC validating ones, so this doesn’t seem like a good trade-off to me.
> 
> Ehh...I can not do that comparison. It's for me a layer violation.
> 
> 1. You must have DNSSEC signed data and do validation to get some security on *any* use of DNS, and given the broken CA mess in the world, the only way to tie that down (for example by informing what CA you use) you do that in DNS.
> 
> 2. You must have TLS (or similar mechanisms) on the application layer to tie that down, with the help of all tools you can get in the lower layers (for example by using DNSSEC and RPKI for the routing).
> 
>>>> or the CA used for the server need to be explicitly tied to the pool configuration. If not then your ISP can easily hi-jack the service in a way that’s not possible with “regular NTS”. Or maybe I am missing something. :-)
>>>
>>> I think Christers idea is good(*), as it collapses to "if you trust your DNS, then you can use SRV". This irrespectively of whether DNSSEC is in use or not.
>>>
>>> That trust can be built by either just trusting DNS, trust the validating recursive resolver run by a third party, or you run your own validating resolver on ::1.
>>
>> This doesn’t seem realistic for most clients, at least of the general pool service.
> 
> Ok, there is something I do not understand here.
> 
> I have been both signing zones and validating them since around 2003. The .SE TLD have been signed since 2007 I think, and >90% of DNS responses in Sweden are validated.
> 
> This is not difficult. At all. And if you do not have your DNS infrastructure up to par with what have been around for >10 years in all mainstream DNS software, then I do not think there is much we in NTS land can do.
> 
>> As Hal said, if your “pool” is all run by one organization it’s really just a cluster and you have reasonable deployment options already.
> 
> Correct. As you know, we do that at Netnod although we have the cluster even more tightly bundled and use IP anycast for the servers.
> 
>>> Saying SRV can not be used because you do not trust DNS is not working, as we have other issues with NTS if we do not trust DNS.
>>
>> For most TLS-based security you don’t need to trust DNS (because a DNS-hijacker won’t have the right TLS certificate); I don’t understand why NTS is different. If DNS is lying/hijacked/bad the NTSKE connection won’t work, right?
> 
> Yes you do have to trust DNS for TLS as DNS include various things that makes TLS robust by including a CAA record in DNS and signing your zone. Else any CA can issue a certificate for your domain. I.e. I disagree with your statement between the lines that is not possible.
> 
> What I agree with is that it is as possible to get a certificate for TLS used in NTS as for TLS used for HTTPS. And in both cases you today to get a robust service must sign the zone, include CAA records and validation must happen.
> 
> There are too many MITM attacks going on against these kind of things to claim TLS alone is ok, because that (as you write) relies on the antagonist not being able to issue/get a valid cert.
> 
>>> NTP Pools rely on us trusting the DNS as the pool is built in DNS as the database.
>>
>> NTS is an opportunity to improve on that. :-)
>>
>> I’ll expand on my suggestion regarding the certificate authority above in a reply to Hal’s message.
> 
> Thanks!
> 
> I do not think we disagree much here. What we disagree on is I claim how much you must trust DNS anyways to get things working when using TLS.
> 
>    Patrik
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
> 