Re: [Ntp] NTS pool support

Leif Johansson <leifj@mnt.se> Mon, 22 July 2019 13:38 UTC

Return-Path: <leifj@mnt.se>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD611202CC for <ntp@ietfa.amsl.com>; Mon, 22 Jul 2019 06:38:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSxSkjchwkgm for <ntp@ietfa.amsl.com>; Mon, 22 Jul 2019 06:38:02 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC6B120286 for <ntp@ietf.org>; Mon, 22 Jul 2019 06:38:02 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id q22so73934298iog.4 for <ntp@ietf.org>; Mon, 22 Jul 2019 06:38:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=to:references:from:openpgp:autocrypt:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LvqxKYSSTiFvYGDmYcnuMdWLghxVkvfqyTyoIiEtu9U=; b=OCUrUq9DAu7egvASVeGGtbyrbGFnCdL4lRZbRSTojvfFj+4EQdfj0VYYzdiLtSqVPZ AatyuSlgguG2iHnJiYadpi2+/hPobotiH4fDtHl3Mwz/Qidtcf7SYCqv/UtOszuCrnXA wky/stdn9xYkGW6Z6SeDrD6WPuFMNLWQf4Q76xc2gC7+zAFhl15efDnzMRsp0hdbk5bR OrkG0Gdp0uFim06R5I+iNuqAHiGPBiOslBDtm9yrpBNiDv/5jK4erVoe1nk0/IuW080p WbziwmlXkpXhtclgb6zXWdvznsMR+tD/mPq5/y7br7gMv0D6s5bp4PRi46N5JrXh6+AK d/ig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:openpgp:autocrypt:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=LvqxKYSSTiFvYGDmYcnuMdWLghxVkvfqyTyoIiEtu9U=; b=WsMDw2wsGgEsDq6o4O+UU5bhkOEub3rGwSnwfquvdvfN7Ho2FhCrkeCOn9HnYelN2g Iy8TbamCxYRg+0FdlYY34Gauen/XglRFQAtf6xrsNIj0TCc0Aazt+K6Z/HXGKArGb7wA IsQVwj2yFXwlnVY/k+nowKnh7IFQkQYC5jAwSp+v5WAi200PQ6RcdRSmXXQuyLyTiq16 dslnLTjyDiuACfeup6WkF2PwviVpAnhpJBykmmN3YLetirM11yH9kUtzT0xHqxy/of2n nJNPMXjD3RKI/0hNtfnVH3sBBOLp81O5I+wlMFRKVYs2CinFBZXN4ASkeZjgJrzDr7GR Vmdg==
X-Gm-Message-State: APjAAAXLkf+9jVXD/IsPcEQLrMV49XBVz42kjJYqbVVQIY/20pvuReQX to473z2LmBCkoq7hk7J1WwfwdHJ8p28=
X-Google-Smtp-Source: APXvYqxRGMFiV9lsf/ArZkHDifSLbDslMvNzdf8QDtta1/zzZM1govE5X/JM6fh/89hhaV0iQgyS6w==
X-Received: by 2002:a02:ce52:: with SMTP id y18mr70181776jar.78.1563802681022; Mon, 22 Jul 2019 06:38:01 -0700 (PDT)
Received: from [172.16.154.42] ([207.115.96.130]) by smtp.gmail.com with ESMTPSA id k5sm44504036ioj.47.2019.07.22.06.37.59 for <ntp@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jul 2019 06:38:00 -0700 (PDT)
To: ntp@ietf.org
References: <3cd8c65b-a37c-863e-ea2c-2de0a5aeee96@weinigel.se> <17C0BC71-F9A8-4839-B593-0AF18967F5B6@develooper.com> <D8DF9BEE-7AE0-48D2-9A7F-B98D4F19147B@frobbit.se> <32C3B758-94D3-4530-83A1-5EBE5EF341CA@develooper.com> <C1579956-E21A-455B-A154-DD145D7E20E8@frobbit.se>
From: Leif Johansson <leifj@mnt.se>
Openpgp: preference=signencrypt
Autocrypt: addr=leifj@mnt.se; prefer-encrypt=mutual; keydata= mQGiBD7DfnwRBADpIpOw6bXfx2Yo3vac/j5WzVcWNZKuiYc4uuFnBYxH8zTA5cdwytuOYNte cX1yrPgmObfPVU0EFktdBMFgLE5TNRUMeJZTmAl3QYDm8N32SeSUEb6GPFsUTGgxsCW3GVAo q6DBopKqhR9HT0+crQakbc7XkS4FjeBWiXjuNf/IqwCgyoa2Qfq8UdjbcH+DRGzPnRTeqzEE ALIEsCzDp4HQqXqqNLCoExbgmCrEHvnqFmilCHJVnyuY8LXmcpq2uwJaiIdsTqLeQ8WrMxWg mZc6F9QSdLP6MVZT3v+5OqOZMUDsu4nGom3HH+tG238vMSEF+klGdrI0wdscrY+28Oshjhqj 4FZxCwdNU9RTU8xQ9IoObiEo1yOHBADK9a5GhkLT+d2cb48orETGtG7i//HOnstouw/TmEUX reZPtT6wpIdN9Jf3W80GA6A34VEGA/I+/5e+9nFvINpLvEF2ghJBH+sWwQ8EXpo0M/yir9oG eJI7gpOHRj5Mq9uqFG0wcamInuWgbMP1cefjXusHbHyDFKr7ydWSsZHqXrQdTGVpZiBKb2hh bnNzb24gPGxlaWZqQG1udC5zZT6IYAQTEQIAIAUCSnC8wwIbIwYLCQgHAwIEFQIIAwQWAgMB Ah4BAheAAAoJEPCcfBbWzGZ3x8MAnimIMTFOH4LLfp8bQnSPWm6BQyA6AKCk4S46++PpqtTM 0wIZ+kuYaBtky7kCDQQ+w36FEAgAr1zK1qIIXmoeEqFulgFi17FRpSibNwwge9bkG2+IO7MO m4Ih+f4CRkqaP5U5diiWb4nyQc/Yqzf3TTSE+CH0ghvDCwfZHrzUsVl9t57S2RFKaQhDUUw3 lz0TgKN66z1IRnQEARuz9PFd96pIhLaJBOn0e55Cu5qqJVwGpst3+I3jqT/cxjymRxPz2O6R 9k/ZOOiOGROZYAjNHKcdoeBr7OaIHcPRCi1R8MBKE4HOK1SwaVvs26Fd2enixIOBmyFTkrue 3VgaAd3zrJauD0qa/u5y2kGEyFFJwNsKnoX0aCmNNIG+aKvnSCWfba8bmYOAsbxS2lo4MKmu DM0rrVyLhwADBQf/VzM77aviZ3Ir7qXj0uV/62wyrg8/5flXl8XjuATewD+hTaux1lg5LgPU 9cokMHYHrTsnp79nhEB9qOpsQLX+npae7a27x3zyqLP0V7neyKy1ycuBI9KU9B3ivgSMRlKR 91GcmUpRnKiSnxPYNtq018mY72YYHCpfAh0OOUA88bxbYIuF5cv9dYyOBhNEkI8xB1VOWev1 CPkPb0DwDABHdOBq9e0hT3OUOaat2JPwCEHU2NTGsYFuZRysq8xnxFgHd00+h2OJZ50UYVpB jDxaCj5gvHHFFnmfCLD5VqjEJGi4k2znZHg67i2pw0f5BSq8fsfdUML35LzL/aaZPMzlg4hG BBgRAgAGBQI+w36FAAoJEPCcfBbWzGZ3djcAnAxF3084vKlsRNGcyj/rn5lA4Q+nAKCnjZYX snFG51wbu8OI88aj3LJE5w==
Message-ID: <1bcb33df-75b2-dcff-b813-3d256b182e20@mnt.se>
Date: Mon, 22 Jul 2019 15:37:59 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1
MIME-Version: 1.0
In-Reply-To: <C1579956-E21A-455B-A154-DD145D7E20E8@frobbit.se>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/t2QWbZDOX4zwLnljpdWjsDm1p10>
Subject: Re: [Ntp] NTS pool support
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jul 2019 13:38:11 -0000


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
>