Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps

Eric Rescorla <> Wed, 17 October 2018 13:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C88A7130E83 for <>; Wed, 17 Oct 2018 06:19:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 4yizkREBoxM8 for <>; Wed, 17 Oct 2018 06:19:23 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 50D61130E08 for <>; Wed, 17 Oct 2018 06:19:23 -0700 (PDT)
Received: by with SMTP id p143-v6so8737892lfp.13 for <>; Wed, 17 Oct 2018 06:19:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SiWZto5f8MZuz05rad1zYxbl2YQVdRvQUE9qTR1FJkQ=; b=VOVelg7J92iILbmNMDCEzDuxvzJSpooX42PQFbJeKKPgQkXM1akOxg6IdvIDU8sUik TrA7xESSBV3vkfJPwOo6H2agGqAE6ihJNmzecFleWLnKnnA3flv+LF322ky7MD4O4/Xz 8EZWbl3IrKijZ7y1x1wGxvIy6OIbxkLGO5IlfFjuRFf2LsJzBpwDhSGrVxLsaG6od9Vp 4fihTpA2rOMC24x70klC1L1SWvnw+YAuuv4/+E0+2N3GPUIztCzG6dO5JZmsle4bm+8C E9IYgIohHoyTvT5Rsxuxj442lPyNISF4CxTGESVT+Jga2i/qP4rIy8yrCvPkdy/okws6 NnWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SiWZto5f8MZuz05rad1zYxbl2YQVdRvQUE9qTR1FJkQ=; b=ryUXxsqp86McYN/TFbBp/UQnrmfoUgNIuRtR4MSSRcmSF+dMKf+b8A4BB7hcaG6dJH HEFe5P7Y1/V4q3c5UXh+aI9Yg+9GAfOll+LJm15oGFkeM0qoaBMfEIjxDmeqeBiY11cG zUmsEQbI3p6ul/T0r2cubOlS1IVD55s0ms2ZvJGQ+IxPQa0yIbeMHrk4FyRf615LivNi wG1oX2EyLIGGhsJhygEoH9gLPqi6RE3jwiqJztwjvFcrAi3cXE8xctY94MSlV/IyjDJG V68F1qMzlPrZGmsnzDi/Ybwsdc5ve6gp/WUWZ4EgvWctY8DqcxQIV24yRNmxZirIh6Et EgDg==
X-Gm-Message-State: ABuFfoieVECnmr0gpeZoYA83KjRu0NsuACicsoNEmloZ6bNiFdu4Fg/+ IRChbes5PSfGonzHIJJshmPkKxPLHfpuwOMC34CgBkL3
X-Google-Smtp-Source: ACcGV63x82eZ4wqkW0Fg5cxni4DWDNuC68yCSfk/zsqN9h8/QWCtU6x0TV6X9MzxssZhRHm/M9rrn4f1Dlng3tjR0nA=
X-Received: by 2002:a19:a90f:: with SMTP id s15-v6mr15260065lfe.154.1539782361395; Wed, 17 Oct 2018 06:19:21 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Wed, 17 Oct 2018 06:18:27 -0700
Message-ID: <>
To: Benjamin Kaduk <>
Cc: Daniel Kahn Gillmor <>, "<>" <>
Content-Type: multipart/alternative; boundary="000000000000af0a3205786c84bf"
Archived-At: <>
Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Oct 2018 13:19:33 -0000

I'm responding to Ben here, because I think it's worth adding some clarity.
However, I want to flag that I'm going to be rather short on time for the
few week and not able to spend a lot of time replying to traffic on this
topic. Even more than usual, non-response to some point does not
necessarily indicate agreement.

On Tue, Oct 16, 2018 at 6:15 PM Benjamin Kaduk <> wrote:

> (1) provides a channel for DANE records that is reliable in the absence of
>     an attack

I think this alone would be worthwhile -- and is the purpose I have always
in mind for the draft.

> (2) reduces the ability of an attacker to cause the client to ignore the
>     server's authentication preference
> I think that just meeting the above two conditions could provide enough
> value to merit publishing, even without attempting to add something
> like:
> (3) allows the client to realistically hard-fail connections where DNSSEC
>     validation returns bogus or indeterminate.

I'm not sure I see a meaningful difference between (2) and (3), given
that the mechanism for (2) is likely (3).

> Getting (1) is probably trivial (though with middleboxes you never
> know), and it seems fairly clear that a pinning scheme can provide (2).

Yes, the question is whether such a scheme is worth the other costs that
it imposes (in particular, hostile pinning, and in the version that people
have currently proposed, the ability to break yourself by inconsistent
deployments, though that's at least conceivable fixable). In case it's
not clear, I don't agree with Viktor's "no substantial issues have been
raised" claim.