Re: [Ntp] Draft on using NTS with the pool

Miroslav Lichvar <mlichvar@redhat.com> Mon, 02 March 2020 12:30 UTC

Return-Path: <mlichvar@redhat.com>
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 5816F3A0A28 for <ntp@ietfa.amsl.com>; Mon, 2 Mar 2020 04:30:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.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 MkUONGNXaZtv for <ntp@ietfa.amsl.com>; Mon, 2 Mar 2020 04:30:20 -0800 (PST)
Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 717A03A0A27 for <ntp@ietf.org>; Mon, 2 Mar 2020 04:30:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583152219; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=t9wAbgNK2pUBbYAFwBF3pOfsd6wX9USi3sdC9xaqF68=; b=Y2I0zrNdQGUu/KP4+ZGk2iPK5uYnO5a1w9mqHPA5mTLYe3S0im3jYgRspeus/rdkMbbEr4 5kT2gt4njRt7TEPw0ASYL7bUYePVZDGuHdSBLDoGCkCzd/iSsTaasawGT4IN201if8qdd5 MyBiFCQWa7TiI2YEKPwZGbbrQtd/rFk=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-386-lCwooocGPQ6OCODoGuzSVQ-1; Mon, 02 Mar 2020 07:30:14 -0500
X-MC-Unique: lCwooocGPQ6OCODoGuzSVQ-1
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 215C48010EB for <ntp@ietf.org>; Mon, 2 Mar 2020 12:30:13 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9788287B1A for <ntp@ietf.org>; Mon, 2 Mar 2020 12:30:12 +0000 (UTC)
Date: Mon, 02 Mar 2020 13:30:10 +0100
From: Miroslav Lichvar <mlichvar@redhat.com>
To: ntp@ietf.org
Message-ID: <20200302123010.GA14026@localhost>
References: <CAN2QdAHMwwY4L5ZarVR2q-ZfPuetuv9L9=G-1VBM=WJW-vyTTw@mail.gmail.com>
MIME-Version: 1.0
In-Reply-To: <CAN2QdAHMwwY4L5ZarVR2q-ZfPuetuv9L9=G-1VBM=WJW-vyTTw@mail.gmail.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/ia7SHGF2vCD-x0dRDyuXa_N2Yx0>
Subject: Re: [Ntp] Draft on using NTS with the pool
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, 02 Mar 2020 12:30:22 -0000

On Fri, Feb 28, 2020 at 12:30:26PM -0800, Watson Ladd wrote:
> Hello,
> 
> I've uploaded https://datatracker.ietf.org/doc/draft-ladd-nts-for-ntp-pool/
> which contains a putative mechanism for using NTS with the NTP pool.
> 
> I'd appreciate comments: there is a lot to think through in this, but
> it's important to get NTS adoption. Definitely the draft is in rough
> shape, but sooner seemed better than never.

I think at least on some platforms dependency on SRV and DNSSEC may be
very problematic. I suspect in many cases the NTS client would need to
have its own DNS client in order to get the SRV record and be sure
that the DNS response was validated.

Are there any other protocols that depend on DNSSEC? The few that I'm
familiar with, like SIP or XMPP, don't rely on DNSSEC (certificates
are for the original name, not those from SRV record).

I'm wondering if it would make sense to specify a "redirect" NTS-KE
record, which would tell the NTS-KE client to connect to a different
NTS-KE server without giving any cookies. The client would remember it
for some specified time to decrease the load on the server. This would
be closer to DNS over TLS rather than DNSSEC.

-- 
Miroslav Lichvar