Subject: [Ntp] Of Roughtime's algorithm agility, and host attestation

From: Thomas Peterson <[email-masked]>
Date: Sat, 27 Jul 2019 02:04:21 +0100

In discussions with many folk at IETF 105 (thank you for your time), two 
topics have come up in the design of Roughtime:

1. How does a Roughtime client attest the certificate presented matches 
the host that was contacted?
2. Ed25519 may not be secure forever. How do we ensure more robust 
options are made available?

To answer the first point, one suggestion by Erik Klein[0] is to create 
a new DNS RR type that includes the long term certificate of the 
Roughtime server. Should this mismatch the host that is being contacted 
for Roughtime information, clients should consider tampering. It's not 
clear what clients should do if this record was absent. This is perhaps 
a simpler approach that using existing public CA infrastructure that 
supports TLS and S/MIME, but comes with trade-offs.

Q. Do people have thoughts on creating a new DNS RR Type to support 
this, or given the threat and operation model believe we should take a 
different approach?

On the second point regarding algorithm agility, one possible thought 
would be the creation of an IANA registry for Roughtime supported 
schemes. This would more ideal than attempting to piggy-back other 
existing registries (e.g. TLS, which includes legacy such as RSA).

Q. Does the list have a view on this and it's impact to client and 
server negotiation?

Regards

0: 
https://groups.google.com/a/chromium.org/d/msg/proto-roughtime/RVlx6hGeO1U/Dn3zER5JCQAJ

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 27 Jul 2019 01:20:11 +0000

Roughtime server.

Look at https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-00 which attempts to provide various useful information. One possibility is a "cert digest" field.  Certs are generally too big for DNS, only keys appear.

For crypto types, re-use an existing registry and profile it to make things MUST NOT.  There are various options, including TLS, JOSE, etc.

---

From: Robert Nagy <[email-masked]>
Date: Fri, 26 Jul 2019 22:05:31 -0500

This seems within the use case of the already existing TLSA records in DNS. Unless I missed something. 

Robert Nagy
CEO/ Senior Dive Master
DeepDive Networking, Inc
C: 408.480.5133
www.deepdivenetworking.com

Sent from my iPhone

> On Jul 26, 2019, at 8:20 PM, Salz, Rich <[email-masked]> wrote:
> 
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Watson Ladd <[email-masked]>
Date: Fri, 26 Jul 2019 22:48:00 -0700

> the host that was contacted?

You hardcode the key.

> options are made available?

When and if a post-quantum signature scheme becomes available, we can
cross that bridge.

It's likely the protocol will require significant work (perhaps even
switching to TCP) in that case.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 27 Jul 2019 07:51:18 +0200

> This seems within the use case of the already existing TLSA records in DNS. Unless I missed something.

+1

Don't create anything new.

  Patrik

---

From: Watson Ladd <[email-masked]>
Date: Fri, 26 Jul 2019 22:58:22 -0700

> Don't create anything new.

It seems people are misunderstanding the trust relationship here. The
goal is to have publically observable, auditable performance and
identities tied to that. So it makes very little sense to link these
identities to another naming system, but maybe this is a better idea
then it seems. In particular public keys really shouldn't change: that
could permit the laundering of errors, which we very much don't want.

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 27 Jul 2019 08:32:52 +0200

On 27 Jul 2019, at 7:58, Watson Ladd wrote:

> It seems people are misunderstanding the trust relationship here. The goal is to have publically observable, auditable performance and identities tied to that. So it makes very little sense to link these identities to another naming system, but maybe this is a better idea then it seems. In particular public keys really shouldn't change: that could permit the laundering of errors, which we very much don't want.

Ahhh...ok, sorry. I did not write enough words.

I agree with the base idea in what you write here. One should be careful on what one trust. But, one also need to base the trust on something, some root.

This can of course as some have suggested a cert for some time service one trust. Or the root CA of something else. Like root in some other naming system.

My answer was "just" responding to the question whether we should in the case some cert is stored in DNS create a new RRType, which is something I find not necessary as TLSA exists.

   Patrik

---

From: Watson Ladd <[email-masked]>
Date: Fri, 26 Jul 2019 23:54:14 -0700

> This can of course as some have suggested a cert for some time service one trust. Or the root CA of something else. Like root in some other naming system.

I consider roughtime analogous to certificate transparency: the point
is not that Nimbus or Behind the Sofa are necessarily run by good
people or that the certs are logged by them, but that for the past X
they have dutifully logged each one, and if they were to fail to,
there would be incontestable proof of malfeasance. Nothing is really
rooted in the assertion of identity which is sort of irrelevant here.