IETF Logo Mail Archive

Re: [Acme] TXT records for storing certificates in the DNS [invalid signature!]

"Sebastian Nielsen" <sebastian@sebbe.eu> Tue, 16 January 2018 17:06 UTC

Return-Path: <sebastian@sebbe.eu>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61C3129515 for <acme@ietfa.amsl.com>; Tue, 16 Jan 2018 09:06:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level:
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sebbe.eu
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 5acOZgb7GkWU for <acme@ietfa.amsl.com>; Tue, 16 Jan 2018 09:06:29 -0800 (PST)
Received: from dns2.sebbe.eu (dns2.sebbe.eu [IPv6:2001:470:dff1:1:10::2]) (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 DB044131556 for <acme@ietf.org>; Tue, 16 Jan 2018 09:06:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sebbe.eu; s=root; h=Content-Type:MIME-Version:Subject:References:In-Reply-To: Message-ID:Cc:To:From:Date; bh=Jov7QIQVdIDo9fWs6lFk7ADXXNS937adAyCYpsJFkfo=; b=WpVb4WqLW/Cr1S6dpBmTMLtLllgjqleAJHvQ79un5zJ6JJ8mksrDimkCWTJdMvdeBGYGN8Gxn/ A4hGFjfBTB/V8BOKlUxbSNUMdWqktfy972d+HjqEA9rGo4O+KknV1Az/99JJHPRrpwDfiaKo/xv/4 MZXmJOKVsyW380EUHHw8=;
Received: from localhost ([127.0.0.1] helo=linuxlite-desktop) by linuxlite-desktop with esmtp (Exim 4.86_2) (envelope-from <sebastian@sebbe.eu>) id 1ebUgs-0007U5-I9; Tue, 16 Jan 2018 18:06:26 +0100
Received: from [192.168.4.100] (helo=DESKTOPA8GMOTG) by linuxlite-desktop with esmtpa (Exim 4.86_2) (envelope-from <sebastian@sebbe.eu>) id 1ebUgs-0007U1-6g; Tue, 16 Jan 2018 18:06:26 +0100
Date: Tue, 16 Jan 2018 18:06:25 +0100
From: Sebastian Nielsen <sebastian@sebbe.eu>
To: 'Jim Reid' <jim@rfc1035.com>
Cc: acme@ietf.org
Message-ID: <004601d38eec$5739d3f0$05ad7bd0$@sebbe.eu>
In-Reply-To: <62EE60CA-D552-4971-9BC9-7FE88801DE58@rfc1035.com>
References: <1a6f7bfb-d6dc-bd1a-fcb5-ec78ec4497cf@eff.org> <001501d38ee5$240cf400$6c26dc00$@sebbe.eu> <62EE60CA-D552-4971-9BC9-7FE88801DE58@rfc1035.com>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----=_Part_42_324141911.1516122386524"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQF4Hmo1vyBldJvOixf+giIU9eXDGQEMNPbzAVroB66kGmC/wA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/8MY2x2uPPVFnCy0dLso0T6mZARs>
Subject: Re: [Acme] TXT records for storing certificates in the DNS [invalid signature!]
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jan 2018 17:06:31 -0000

Splitting certificates in DNS could be done for example:
0.certificate.mydomain.com = first part of cert
1.certificate.mydomain.com = second part of cert
and so on.

Or even a separate zonefile:
0.certificate.invalid = first part
1.certificate.invalid = second part
as your application/web servers does directly know the IP of the DNS server
and can do a direct query.

But if the DNS client of the servers support very long records, you could
aswell put the whole certificate there.

My tought was that since its only used internally to distribute certificates
out of you DNS server to your web/application servers without incurring
additional server software (and additional security risks), it does not need
to be the "correct" RRTypes (as some DNS clients does not support TLSA or
CERT records).

You could even hide these records from the public and only allow the IPs of
the web/application servers in question to lookup them, if you don't want
lots of "unneccessary" TXT records confusing the public.


-----Ursprungligt meddelande-----
Från: Jim Reid [mailto:jim@rfc1035.com] 
Skickat: den 16 januari 2018 17:58
Till: Sebastian Nielsen <sebastian@sebbe.eu>
Kopia: acme@ietf.org
Ämne: TXT records for storing certificates in the DNS [invalid signature!]



> On 16 Jan 2018, at 16:14, Sebastian Nielsen <sebastian@sebbe.eu> wrote:
> 
> Then you have a script that publishes the certificate. You could ACTUALLY
publish the certificate in the DNS zone as a TXT.

That would be a *remarkably* bad thing to do. More so when there already are
RRtypes for storing certificates in the DNS (TLSA and CERT). TXT records get
(mis)used for all sorts of things and it doesn't make sense to heap even
more on to that existing babble. Or figuring out how to separate certificate
favoured TXT records from any other TXT records that are floating about.

> Each TXT record may only contain up to 255 characters, but you could
easily split it up to multiple records.

Nope. A TXT record can hold up to 65535 bytes. The name of the TXT record is
limited to 255 characters.

Splitting a certificate into multiple TXT records is another very bad idea.
How would something know which TXT records need to be sorted/merged to
reassemble the original string? Now suppose one of those TXT records got
dropped from the Additional Section of a response. How would a client (know
how to) recover from that? These are rhetorical questions BTW.

v2.23.0 | Report a Bug | By Email