Subject: [dns-privacy] New Version Notification for draft-bretelle-dprive-dot-spki-in-ns-name-00.txt

From: manu tman <[email-masked]>
Date: Mon, 11 Mar 2019 09:20:41 -0700

Hi all,

I have captured in a draft the mechanism I used during IETF 103 hackathon
and which is available aan experimental module in knot-resolver[0]. I was
taken short with time before cit-off date, but I hope this will better
explain how it works.

Manu

[0]
https://gitlab.labs.nic.cz/knot/knot-resolver/tree/master/modules/experimental_dot_auth

———

A new version of I-D, draft-bretelle-dprive-dot-spki-in-ns-name-00.txt

has been successfully submitted by Emmanuel Bretelle and posted to the

IETF repository.

Name: draft-bretelle-dprive-dot-spki-in-ns-name

Revision: 00

Title: Encoding DNS-over-TLS (DoT) Subject Public Key Info (SPKI) in Name
Server name

Document date: 2019-03-11

Group: Individual Submission

Pages: 7

URL:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dbretelle-2Ddprive-2Ddot-2Dspki-2Din-2Dns-2Dname-2D00.txt&d=DwICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=aRgHK985qD76PXQaxDKSjA&m=jSTn0YgV5vZZxmSgDChO302kZVyakva0HQhlXmV_Ks0&s=9TmF-DXxE_0nJ6WyhRNoNSiya3N7h_pVwyRn4qIfD7U&e=

Status:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbretelle-2Ddprive-2Ddot-2Dspki-2Din-2Dns-2Dname_&d=DwICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=aRgHK985qD76PXQaxDKSjA&m=jSTn0YgV5vZZxmSgDChO302kZVyakva0HQhlXmV_Ks0&s=5eZd00_oyy5t1SFYXYCMfv1fSl22SudK5I3pkCozKFs&e=

Htmlized:
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbretelle-2Ddprive-2Ddot-2Dspki-2Din-2Dns-2Dname-2D00&d=DwICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=aRgHK985qD76PXQaxDKSjA&m=jSTn0YgV5vZZxmSgDChO302kZVyakva0HQhlXmV_Ks0&s=ZTRurE9sjAPDCKcx8dBXgYPs0dE9LmmJ194vl04cn3Q&e=

Htmlized:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dbretelle-2Ddprive-2Ddot-2Dspki-2Din-2Dns-2Dname&d=DwICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=aRgHK985qD76PXQaxDKSjA&m=jSTn0YgV5vZZxmSgDChO302kZVyakva0HQhlXmV_Ks0&s=H0At0r1sQEdFc1snO7kIVALaFf-F1zRRHGPf3aUqkk4&e=

Abstract:

This document describes a mechanism to exchange the Subject Public

Key Info (SPKI) ([RFC5280] Section 4.1.2.7) fingerprint associated

with a DNS-over-TLS (DoT [RFC7858]) authoritative server by encoding

it as part of its name. The fingerprint can thereafter be used to

validate the certificate received from the DoT server as well as

being able to discover support for DoT on the server.

Please note that it may take a couple of minutes from the time of submission

until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "A. Schulze" <[email-masked]>
Date: Mon, 11 Mar 2019 20:12:41 +0100

Am 11.03.19 um 17:20 schrieb manu tman:
> I have captured in a draft the mechanism I used during IETF 103 hackathon and which is available aan experimental module in knot-resolver[0].
>  I was taken short with time before cit-off date, but I hope this will better explain how it works.

Hello,

for many years I run a dnscurve proxy [1] infront of my nameservers.
Worked perfect but virtually nobody used the encryption feature.
So, the draft *is* interesting to me...

two points comes to my mind while reading the draft:

1.
key rotation is hard.

2.
what's the reason for "In opportunistic mode, the resolver MUST use the authoritative name server despite the failure." ?
A server operator can't distinguish between a resolver in strict mode an a resolver in opportunistic mode TOGETHER with a failure (on server side?)
An other option is to force any resolver supporting "dot-" names to fall back on port 53.

Andreas

[1] http://curvedns.on2it.net/

---

From: manu tman <[email-masked]>
Date: Mon, 11 Mar 2019 18:16:56 -0700

Thanks Andreas,

> what's the reason for "In opportunistic mode, the resolver MUST use the
authoritative name server despite the failure." ?
> A server operator can't distinguish between a resolver in strict mode an
a resolver in opportunistic mode TOGETHER with a failure (on server side?)
> An other option is to force any resolver supporting "dot-" names to fall
back on port 53.

What I meant is roughly around the line of
https://tools.ietf.org/html/draft-bortzmeyer-dprive-resolver-to-auth-01#section-2
. e.g if you operate a resolver in strict mode, and DoT fails (connection
to port 853, fail to validate SPKI) while the name of the name server
indicates that DoT is supported. The resolver should fail.
In opportunistic mode, the resolver will fallback onto port 53. The
operator of the resolver will be setting the mode of operation.

Thanks,
Manu

On Mon, Mar 11, 2019 at 12:12 PM A. Schulze <[email-masked]> wrote:

> > I have captured in a draft the mechanism I used during IETF 103
> hackathon and which is available aan experimental module in
> knot-resolver[0].
> what's the reason for "In opportunistic mode, the resolver MUST use the
> authoritative name server despite the failure." ?
> A server operator can't distinguish between a resolver in strict mode an a
> resolver in opportunistic mode TOGETHER with a failure (on server side?)
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: "A. Schulze" <[email-masked]>
Date: Tue, 12 Mar 2019 08:14:45 +0100

Hello,

Ah, that makes sense, my reading was to allow the resolver to use 853  
in oportunistic mode even when SPKI validation fail. I've to reread  
the text...

Andreas

---

From: Bob Harold <[email-masked]>
Date: Thu, 14 Mar 2019 11:39:54 -0400

> being able to discover support for DoT on the server.
6.  IANA Considerations

  " TODO: This document requires IANA actions (new RR type)."

What new RR type is needed?  Looks to me like all standard RR's.

-- 
Bob Harold

---

From: manu tman <[email-masked]>
Date: Fri, 15 Mar 2019 00:13:54 -0700

> Thanks Bob!

My mistake, this is a left over from copy/pasta. I removed it from master.

Manu

--