Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

Melinda Shore <> Thu, 05 July 2018 02:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 22025130D7A for <>; Wed, 4 Jul 2018 19:51:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lPq0WDkDpTyO for <>; Wed, 4 Jul 2018 19:51:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5B14F12D949 for <>; Wed, 4 Jul 2018 19:51:49 -0700 (PDT)
Received: by with SMTP id s21-v6so4044122pfm.6 for <>; Wed, 04 Jul 2018 19:51:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=sa2k5ZD3yCQnoqnFvvFW1Zuq6S2y+zYKUlirumDags0=; b=mtdC7oEwl2GR5pg0r1epG9g57MQFuinMkf9jfaiO0Ve6utunMYLrbTJmfU4MkyQ1j2 l0HV2mB6ePT3vKwBuqUtPNjXai7Bm5R7UfrEFZDMDf634tmSwniM1G1JxQPv2Pdk8qd4 BGCJSFGqkvckjc3JtnNTcrANJ43pW0DEgzBtcaGrLa0ZbfGnQspJogevPyVJni8hCi1e Be5aIOa5F3dNMx96O2G3Ags6BShC5R0fu/rUWirads0TNxA/Ly2kwRU7GU2z18ydij21 Rt9XcWLhK9+NNMZ8tokNcHBdoijfJdhyyo6DyHKAubfcFXqQ6abeey7zzVJziRL/qqe7 e9yA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sa2k5ZD3yCQnoqnFvvFW1Zuq6S2y+zYKUlirumDags0=; b=o8Yl2WoZKJRkZt/IXvBQ5o3b39kJtqs9HU0+7zdK09fBUvv5fumAHc3y2bGyJ/0ClV NbNzsLq9mlD5fp/vIN2mQNmom/CJR2UyqqZ6SF+Rh0UKjETb3WMEGJjXyAGFsr8qAb+e MVTEwwQz64CAXB2i3Xkbo/O/e/hVfuoPw2bAR2PSjx0alvbke3AJ+bd3j3hoorXYv4W0 Nv7n/bhSikc/wbnejHkgtQUJkCmfjrAhPkOW3wO7Ic+9ROpotU9yVirRQsDuyFClrHOn aoAKTE/mkTVv/7po/UYlmyvlgsFZbsUYeKGb3ULk4hAjeloC9/83ORu1BdocCSfPXkJv /YHQ==
X-Gm-Message-State: APt69E23PDxol+f2gHhOFgkmroon0NrKBPlw0gJQInO6F83xjrxEroYP D02picqgOUUkU3a/67rhteAcoRE=
X-Google-Smtp-Source: AAOMgpdYIbWYcmhAsnj1mOU9E4R81LYQrS/KUMBZbDO4fUDFv9rcEFhotFmNZW9grE4WowTDXhCyZQ==
X-Received: by 2002:a65:62cd:: with SMTP id m13-v6mr3866082pgv.280.1530759108454; Wed, 04 Jul 2018 19:51:48 -0700 (PDT)
Received: from aspen.local ( []) by with ESMTPSA id a24-v6sm16103853pfj.140.2018. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jul 2018 19:51:47 -0700 (PDT)
References: <> <> <> <> <>
From: Melinda Shore <>
Message-ID: <>
Date: Wed, 4 Jul 2018 18:51:46 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Jul 2018 02:51:52 -0000

On 7/4/18 6:33 PM, Viktor Dukhovni wrote:
> I thought the authors wanted this done quickly, but lately they
> seem to be in no rush to get the document finished. 

I'm still trying to figure out a way forward that's useful
for the people who intend to use this extension and that doesn't
add cruft or ambiguity.  Unfortunately there doesn't appear to
be one, so compromise is necessary.

I also think there's been already been a pretty serious process abuse
here and tend to think that the new implication that we can go forward
in a timely way if everybody just agrees with you is additionally
problematic.  But as I said earlier, I'll go along with the working
group consensus and will not block a decision I don't happen to like.
That's the implicit contract we sign with the IETF when we decide to
bring work here.


Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
                 34C0 DFB8 9172 9A76 DB8F