IETF Logo Mail Archive

Re: [TLS] Enforcing Protocol Invariants

Jim Reid <jim@rfc1035.com> Fri, 09 November 2018 01:42 UTC

Return-Path: <jim@rfc1035.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF88128D0C for <tls@ietfa.amsl.com>; Thu, 8 Nov 2018 17:42:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 BvwldKFLNoXo for <tls@ietfa.amsl.com>; Thu, 8 Nov 2018 17:42:00 -0800 (PST)
Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1017D130DD5 for <tls@ietf.org>; Thu, 8 Nov 2018 17:41:56 -0800 (PST)
Received: from dhcp-919c.meeting.ietf.org (dhcp-919c.meeting.ietf.org [31.133.145.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 35E022420FDE; Fri, 9 Nov 2018 01:41:53 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <CAO7N=i0g9d9x5RdF_guKm3GDAxVRHSV+eHffs6kiJm6dWO7tvw@mail.gmail.com>
Date: Fri, 09 Nov 2018 01:41:48 +0000
Cc: tls@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A8C7543-2791-4ECF-9B35-77F386D41F31@rfc1035.com>
References: <CAO7N=i0g9d9x5RdF_guKm3GDAxVRHSV+eHffs6kiJm6dWO7tvw@mail.gmail.com>
To: Ryan Carboni <ryacko@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/R70G61MNPT-s9u8nw9-yujlnJE4>
Subject: Re: [TLS] Enforcing Protocol Invariants
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Nov 2018 01:42:01 -0000

On 8 Nov 2018, at 08:44, Ryan Carboni <ryacko@gmail.com> wrote:
> 
> This might be a radical proposal, but maybe the certificate hash could be placed in a DNS TXT record.

This is a bad idea.

Overloading TXT records with special semantics rarely, if ever, has a happy ending. For instance application software would need to somehow work out which of the TXT records for some domain name was your hypothetical hash and which were SPF strings or whatever else has been dumped into TXT records.

If you need to put this hash in the DNS, you might as well get a type code assigned for a specifc RR to do that.

v2.23.0 | Report a Bug | By Email