Re: [Ntp] NTS pool support

"Patrik Fältström " <paf@frobbit.se> Mon, 22 July 2019 04:02 UTC

Return-Path: <paf@frobbit.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 56A1212007C for <ntp@ietfa.amsl.com>; Sun, 21 Jul 2019 21:02:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=frobbit.se
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 GD5JSVfBSRaX for <ntp@ietfa.amsl.com>; Sun, 21 Jul 2019 21:02:24 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E3E120041 for <ntp@ietf.org>; Sun, 21 Jul 2019 21:02:23 -0700 (PDT)
Received: from [192.165.72.198] (unknown [IPv6:2a02:80:3ffc:0:7c0d:3d4f:876a:24ce]) by mail.frobbit.se (Postfix) with ESMTPSA id 84FCE26FEA; Mon, 22 Jul 2019 06:02:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1563768140; bh=XyI/TsV5VK84XLyHa28blEPDfAcwwSoowF1su6zZItE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Z592MMOxmyEtEGMD8hBma396owlh5cakjV8SokJBI6Knl5cAZiT3VsrEtMh9O7mn6 osRmtkSyJ7FXD9/q6PeP9T2SCdKn2oONMwYO1tcJLODXhDcSOS5bYrmaWvtAEcRFtN Cs/bTDX+Ll9PHf6mErh/QI5oDKHD+cu6Ea6Uz4X4=
From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" <paf@frobbit.se>
To: "Hal Murray" <hmurray@megapathdsl.net>
Cc: "Christer Weinigel" <christer@weinigel.se>, ntp@ietf.org
Date: Mon, 22 Jul 2019 06:02:19 +0200
X-Mailer: MailMate (1.12.5r5635)
Message-ID: <D18D784B-B21D-4222-8462-2816539C9CEF@frobbit.se>
In-Reply-To: <20190721221505.ECA5C40605C@ip-64-139-1-69.sjc.megapath.net>
References: <20190721221505.ECA5C40605C@ip-64-139-1-69.sjc.megapath.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_54331869-5FB5-456C-8B4F-283F3507F062_="; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/bh24xHgNFTe3-IxbFsqu_Jmrj8Q>
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 04:02:26 -0000

On 22 Jul 2019, at 0:15, Hal Murray wrote:

> If we trust DNS we could use real DNS/SRV records.

There are a few different approaches if one look at DNS:

- SRV

_prefix.domain. SRV port host

- NAPTR

domain. NAPTR service_type port host [sort of]

- URI

_prefix.domain. URI uri

> I'm not a DNS wizard.  I don't know how to setup DNSSEC.

DNSSEC consists of two parts:

1. Have a zone signed. Or in reality, each RRSet (all records of the same type, class and domain name) is signed by adding a signature to it, using asymmetric keys.

2. Have a signed response (i.e. RRSet) validated when it is sent as a response to a query.

Many people mix up the two.

> I'd be happy to use DNS/SRV if we find a DNS wizard who can point to a simple HOWTO type document that tells how to secure DNS.  We may need a separate document for each OS/distro.

Yes and no.

I think we should decide what we build the trust on, and where we se risks. We could say "for this to work, zone with records should be signed, and validation should happen or else the following attack vector exists".

For "how to use DNS", we must refer to DNS material. Like we do with other non-NTP stuff. And how non-NTP people should refer to us.

I do not want to write the "NTS for DNS people" guide :-)

> What's the general status of DNSSEC these days?

Regarding the two functions I talked about above:

- Signed zones is pretty good. Almost all TLDs are signed, which means if you have a domain in a signed TLD you should be able to sign your zone. You can do it automatically for example in Bind or other software, and many DNS providers automatically sign your zone even if you do not ask for it. The trouble is that whenever you have signed your zone, the public key you use for signing must be sent to the registry of the TLD where you have your domain, so that it can be signed and a chain of trust can be built. Not a problem unless you roll your keys.

- Validation is easy to do by "just" turning it on in your resolver. Unbound do it automatically for you for example. If you use your ISP resolver, the result varies. Google open DNS 8.8.8.8 and as far as I know all open DNS resolvers do validate DNSSEC signed responses.

> Is it ready for prime time?

Absolutely!

> Should we be using it to help build critical mass?

DNS people like me think one definitely can build other things like NTS using DNSSEC, given you first have something like rough time as the digital signatures in DNSSEC can be validated :-)

That said, we should write "you must have a DNSSEC chain of trust, or else build an equivalent chain of trust in some other way".

> Or using something else until more OSes/distros have good support?

It's all in there. It is not always deployed because people are lazy. Like IPv6. Similar syndrom. Although DNSSEC can be deployed even if your ISP have not deployed it. IPv6 is hard if you can not get IPv6 transit.

> Is there a simple/portable API to get SRV records?

Only the normal DNS API "one level deeper" than gethostbyname. But not more hard that that. You can still do sync calls, and do not have to deal with async socket stuff.

   Patrik