Re: DNSSEC architecture vs reality

Michael Thomas <mike@mtcc.com> Tue, 13 April 2021 00:48 UTC

Return-Path: <mike@fresheez.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A053A190D for <ietf@ietfa.amsl.com>; Mon, 12 Apr 2021 17:48:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.751
X-Spam-Level:
X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc.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 UKyGjRTlK9Fh for <ietf@ietfa.amsl.com>; Mon, 12 Apr 2021 17:48:52 -0700 (PDT)
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 C953C3A190C for <ietf@ietf.org>; Mon, 12 Apr 2021 17:48:52 -0700 (PDT)
Received: by mail-pj1-x102c.google.com with SMTP id u11so3915741pjr.0 for <ietf@ietf.org>; Mon, 12 Apr 2021 17:48:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=V6UyNfrJc+ncknAJeOIVkageFyYuMyCHLxzuhmkoeYU=; b=cyaRFEvj8+W2+MTmvZiI3/7C+0l9hH0IOq7nkY5KdYrAZWhq/aCuDJeNoP/ueeHtDV SRyTpNTL2v1hxr7dd5epoDYaCf1Aznm9304pUch6NNbohJ71AMPytNid4H/HSMgQA/qB vez6dyZ+9lenilldvjqFmPHttAiE9vuhnOmxm4OeEWayRKMGp9Y1nsVcHEBsZxkcos50 jF4P+1Tc25JKE1wn1y6DWUXcYha8JUXQdr/iZZ13PegPx6MENY7CnhXYCW9uZrkubxXR MEictZaNpmDGCi5ymKW3XyBW2Z46n9+xk68oNMLOAHNBxUFs1wDxMCKhxJv2yvQv45LD PxrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=V6UyNfrJc+ncknAJeOIVkageFyYuMyCHLxzuhmkoeYU=; b=GhGlvjFbLxw4hWUcztAKpri0qsKgbsY1qLnGubXSqWpE5yVdaokJX1zCj0ux7JON4i FsU271hltWwmaBhQBUK5YoQ9X5rhqdoqctbMbLjH+Ius1mMYmLvlHBw1Iw75l6nSrMUc m0XWF97Q9Bni3BtvkFLaApDYqsrxgTmvZ83k4MDpA0lYcZVJz6B22oXvNm9UAoxW4DE4 MrAGv71HXcsX6eEhoBbq0cOtdjBWArpc/sNCvFwI2DPRGSff4RUZ4yCHMxuX8G1CNfYB LsyP1kgLdPFXIyAsUSr8GzrreT6yxegAXM6hFodYLAwttegAu48VvsMctsUe8/zZ5I33 tMgg==
X-Gm-Message-State: AOAM532jiCRMmoLtwYVvOGZUGbE6JRAUcpn6A1K5tpXpDEyY7jzea3Zf TVfwM1ZHAFQITUB1b0AftjHPV9Wyi6k/gQ==
X-Google-Smtp-Source: ABdhPJwhSJGW5osiFmPCMp5N0P1kUmy9SEhRErq9lsanMa87PrnMlTCNgdYDkwWJuVB/izug3gCfDw==
X-Received: by 2002:a17:90a:d41:: with SMTP id 1mr2086479pju.232.1618274931135; Mon, 12 Apr 2021 17:48:51 -0700 (PDT)
Received: from mike-mac.lan (107-182-38-56.volcanocom.com. [107.182.38.56]) by smtp.gmail.com with ESMTPSA id fw24sm498684pjb.21.2021.04.12.17.48.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Apr 2021 17:48:50 -0700 (PDT)
Subject: Re: DNSSEC architecture vs reality
To: John C Klensin <john-ietf@jck.com>, Nico Williams <nico@cryptonector.com>
Cc: ietf@ietf.org
References: <YHN5ObR0eqea8Mrc@straasha.imrryr.org> <CABrd9SRdw9baHD5-j9nz4Zv5JjfL35TgaTvS787orEyGxZdKzA@mail.gmail.com> <YHOAzeOj1JaGdmsO@straasha.imrryr.org> <5e91c054-5935-df07-e8ba-09cc78f6c950@network-heretics.com> <YHPSP8Kij2K4v7qQ@straasha.imrryr.org> <82c5fcc6-b419-6efb-b682-b5dbb32905e2@network-heretics.com> <585D8590-472B-4CBC-8292-5BE85521DD76@gmail.com> <a6545baf-b15e-3690-d7b5-be33c4078e02@mtcc.com> <20210412221435.GV9612@localhost> <0755b70e-cc8e-3404-73cd-51950b3d7e53@mtcc.com> <20210412222748.GW9612@localhost> <b0a43f25-c4c2-9f3c-1a42-426a6ef6afa0@mtcc.com> <5F7F84363A52E9AB79CBF9B2@PSB>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <06a8c3ef-3cd0-e287-b749-d874d9217ecf@mtcc.com>
Date: Mon, 12 Apr 2021 17:48:48 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <5F7F84363A52E9AB79CBF9B2@PSB>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ZHN1m__97ckrEhg703ypYoNpFUQ>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Apr 2021 00:48:54 -0000

On 4/12/21 5:42 PM, John C Klensin wrote:
>
> --On Monday, April 12, 2021 15:43 -0700 Michael Thomas
> <mike@mtcc.com> wrote:
>
>> The one thing that bugs me about DANE is its use of a native
>> RR type. This is a well trodden argument of doing it proper
>> and doing it in a deployable way. We know what happens when
>> you do it the "right way" which is usually nothing at all. If
>> it started to get popular, we could gin up a TXT record
>> alternative though, I suppose. When we were doing DKIM at
>> Cisco, our IT folks were incredibly accommodating, but
>> implementing a new RR type in their infrastructure would have
>> probably been a bridge too far. Heck, I wouldn't be surprised
>> if Mark at Y! got told the same thing :)
> And I don't want to reopen that argument, but part of it is that
> the original plan for TXT RR was essentially as a comment field
> that anyone could put anything into that they wanted to convey
> to another human.  So, if it is used to express protocol
> information, figuring out which protocol and whether the data
> field is correct for that protocol is basically a matter for
> heuristics, no matter how good one can make them.  If there is a
> choice, that is not a really good idea.  Also, it has been years
> since I was involved in large-scale DNS operations (and, by
> today's standards for "large", I never have been),  but it seems
> to me that, if a particular implementation or operational setup
> makes it as hard to deal with a new RR type as your comment
> above suggests, there is something seriously wrong with that
> setup.   And I think the language in 1034/1035 is consistent
> with that view.

Oh, don't get me wrong: using TXT records is a colossal hack. But 
operational considerations are like stubborn facts. We had to bite the 
bullet and accept NAT's too. You feel unclean and want to wash your 
hands repeatedly, but you do what you have to do.

Mike