Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

Benjamin Kaduk <> Wed, 11 April 2018 17:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A944812785F for <>; Wed, 11 Apr 2018 10:33:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Status: No, score=-2.711 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 jYEx3X3BR-kS for <>; Wed, 11 Apr 2018 10:33:51 -0700 (PDT)
Received: from ( [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B91DC12025C for <>; Wed, 11 Apr 2018 10:33:51 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id w3BHT0fk002146; Wed, 11 Apr 2018 18:33:51 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=Sk6cB4d187v1U+5f9pC/A0NpxaY2fBRw9wEouoUcDW4=; b=W65XB6t2wN1qyWAzLpqHLmThrKLn8/fp6ytM7mTm4pniHlpwOCdRLYKUsMTKkJ3yTgm+ P++RUSxnDf9EplyJaVn8ehfCGWNqgvTtbUTWuke5ZkPPtCqmQza43xTMGYeS3r9/LVzD MJz6gOXU3tSM9uRpnN+LnO0+XR9tlGQfOVYcT1R+crRYvj/V3rs8WWzhJT8ZkPO9cxm1 KmoepMAW9t+Dnj3Yaw4lxEXNhulBZlezWh+GgtjTHFqKd56ubNrJcM/nGGFL1OOeWIAO H8TRsL9xKyqlqhB8+PNVr3OS+u2DUbmuLdpZ3QeTqX/+c5C/GqmdZpxJUqnDBF9TffdT UQ==
Received: from prod-mail-ppoint3 ([]) by with ESMTP id 2h9edu9fqm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Apr 2018 18:33:50 +0100
Received: from pps.filterd ( []) by ( with SMTP id w3BHWVXV019167; Wed, 11 Apr 2018 13:33:49 -0400
Received: from ([]) by with ESMTP id 2h78phxm7w-1; Wed, 11 Apr 2018 13:33:49 -0400
Received: from ( []) by (Postfix) with ESMTP id 74FE282F79; Wed, 11 Apr 2018 17:33:49 +0000 (GMT)
Received: from bkaduk by with local (Exim 4.86_2) (envelope-from <>) id 1f6Jcy-0003gF-FH; Wed, 11 Apr 2018 12:33:48 -0500
Date: Wed, 11 Apr 2018 12:33:48 -0500
From: Benjamin Kaduk <>
To: Nico Williams <>
Cc: "<>" <>
Message-ID: <>
References: <> <> <20180410235321.GR25259@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20180410235321.GR25259@localhost>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-11_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804110163
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-11_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804110162
Archived-At: <>
Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
X-Mailman-Version: 2.1.22
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, 11 Apr 2018 17:33:54 -0000

On Tue, Apr 10, 2018 at 06:53:21PM -0500, Nico Williams wrote:
> On Tue, Apr 10, 2018 at 09:48:24AM -0400, Shumon Huque wrote:
> Assertion of facts not in evidence.  We're here because there is a

That argument cuts in many directions, of course.

> question as to consensus (and/or process).  We need to address that.

I don't really agree with that characterization.  To state my understanding,
as responsible AD, of the status of this document: this document is in the
RFC Editor's queue being processed.  The WG is being asked if the late-breaking
issues, raised after consensus was determined, are severe enough to merit
clawing the document back from the RFC Editor to make further changes.
This is, in effect, asking the WG to overturn a previous consensus, which
requires a stronger bar than obtaining an initial consensus from vacuum.

[takes AD hat off]

> I'll be blunt: I do not care about how long it's taken and neither
> should anyone else (besides, it will take longer on the RFC-Editor queue
> anyways; as an RFC author myself, I know this all too well).  I care
> about the quality of the end result, and so should you, and so should
> the WG, IETF, and IESG.
> There is bug in the spec.

This appears to be an assertion of fact without (immediately local) supporting
evidence.  :)

You believe there is a bug in the details of the spec, sure, and I suspect that
this follows naturally from your related belief that there is a bug in the
target scope of the spec.  If we don't agree on what the target scope of the
document should be, then it's unsurprising that we will fail to agree on the
protocol details.

> > Another important facet of this debate that so far has not surfaced
> > on recent mailing list discussions is an assessment of the relative
> > benefits of webpki versus dane, and the recognition that there are
> > strongly divergent views on this topic. [...]
> This is not the subject matter of this LC.

You say this, but to me it seems a relevant factor when determining the
target scope for the spec.  That is, if some individual believes that
DANE is amazing and the Web PKI is crap, then that individual is likely
to want to see DANE take over for the Web PKI in authenticating Web TLS
connections, and as such see that as a vital motivating factor for
any work involving bundling DANE records in the TLS handshake.  Someone
who is less keen on DANE over the Web PKI may not share that enthusiasm
or confidence for focusing the scope on that use case.

> > Viktor has asserted that no-one will be motivated to deploy DANE
> > without protection against PKIX downgrade, because there is no
> > compelling enough additional gain of security. He may be right or
> > wrong, but I've already heard several web folks disagree with him.
> > [...]
> You're not addressing the glaring downgrade attack.

I think this argument would be more compelling if phrased differently.
(N.B. that I don't know *how* compelling it would be, and whether that
would be *sufficiently* compelling to effect change; I just think it could be
more compelling than this phrasing makes it.)

In particular, the question of scope arises again.  My impression is
that at least some proponents of the document as-is want to treat the
scope as something like "we allow for the transport of DNSSEC records over
channels where they were not previously available in a useful fashion" (whether
due to actual blocking or latency considerations), in particular, leaving
the question of how those records are used at the endpoing as out of scope.
You want to bring in the downgrade attack as being a significant risk/drawback
for several, not necessarily all, potential use cases for consumers of the
transport.  The question in this framing then becomes a balance between the
potential/expected scale and importance of the affected use cases and the
unaffected use cases.  This ties in nicely to your new argument about the cost/risk
tradeoff being considered.  To you, the "affected use cases" are potentially
huge (e.g., "all web TLS connections"), and even if someone thinks that the
chance of that happening is somewhat small, the risk of it happening but being
broken by the downgrade attack is magnified by the scale into something that
merits consideration now.  This is to be balanced against
more-certain/more-expected use cases that might be perceived as more "fringe"
and probably as smaller in scale than "all web connections".

I don't expect to get unanimous agreement about the potential scale and likelihood
of various perceived use cases, but would hope that people will consider the
tradeoff to be made, as you have framed it.