Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

Eric Rescorla <> Fri, 09 February 2018 00:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50CE412DA47 for <>; Thu, 8 Feb 2018 16:48:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 y2hCDa-zKTVz for <>; Thu, 8 Feb 2018 16:48:06 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A8A5912DA44 for <>; Thu, 8 Feb 2018 16:48:06 -0800 (PST)
Received: by with SMTP id l11so815819ywh.2 for <>; Thu, 08 Feb 2018 16:48:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=umpgZm2Hm3NnMTz7Qn6+nGKB7MpNKILP3V1n/boYQNQ=; b=BKc3ycaZSozX2atFmZUywKTn8ElXnQeV+5ie5a+A1vPONLdXkUffM2F7ort35c2Ltf csuTJef+zQH5SPI2oxY+pHAKF8xMufeIX/RDdPHMEs+f+QRKQLJGdWb3pkq/1WJ4Q2vf +zG7493FD9tUCL/AqVTzwVccIYjnxsgnU9oNBHO/BdxyEN2ofelXr7wuipwQwYZdv+B3 /CJI1Q82Wn2m60sbW+RGZiN0san2roWdbmzrUrf+iKEvS1XOEH08J3sghuoxljb580qh kmUZe3sQfw7FGAWCgw/iW0KT4i9fvc2KF0fybm8a14eDENQpGwyScxl8eK3L14oJXos/ x2pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=umpgZm2Hm3NnMTz7Qn6+nGKB7MpNKILP3V1n/boYQNQ=; b=kVykTgp5x0w13M6BSepKPT32fzU0BwJxCwBkPFSdYmEVLcIgUzzhkN5Pxov+U+RKe6 7NMFSdfPLtkvp/Tey2/4kptVB/242JWH/yPiNGh7mtymI4PJY07TZzi7mXpQufxhyYdB sTJ12ha5BKP3JIfyhZ4dLKbBJwRl9OJwCuVluJLLhd0w+lRvkgK5Q+1x08IO+YvHhubp /W7LE8PLAYXWArqDaUq5tng9U67AAVxqV+W4afsqFr1iwvu6ekVDcQRbZm/727pdr7nS pEYGkzhzsrXoAQntZM3i+z03ayQ4aas6Vtxl8nzJsldX5yFLw9cleL+8tJEb+YiL8ayY uIvQ==
X-Gm-Message-State: APf1xPA/MZ55j9j8G/4d4ClCkxFn38VGM34IoUbZC9Qg2pN7yjxiSfmL aVOAkoWriwkLr6L9B2bOtyschJq1fB+PmShNr102jA==
X-Google-Smtp-Source: AH8x224AKgFFx9/YwcTvZTkv6YL7EpVFUXnAD+O5rVqdATtxLiGWCC6Jo4Dw6Gd/XbAmfFU1pKysoYtlLNWb0Rl0SnI=
X-Received: by with SMTP id y16mr810394ywg.2.1518137285749; Thu, 08 Feb 2018 16:48:05 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 8 Feb 2018 16:47:25 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Eric Rescorla <>
Date: Thu, 08 Feb 2018 16:47:25 -0800
Message-ID: <>
To: Viktor Dukhovni <>
Cc: Shumon Huque <>, TLS WG <>,, The IESG <>, tls-chairs <>
Content-Type: multipart/alternative; boundary="001a114f89bca349370564bce1ac"
Archived-At: <>
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
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: Fri, 09 Feb 2018 00:48:09 -0000

Yeah this doesn't seem unreasonable


On Thu, Feb 8, 2018 at 8:35 AM, Viktor Dukhovni <>

> > On Feb 8, 2018, at 9:49 AM, Eric Rescorla <> wrote:
> >
> >> This depends on the mode of DANE in use (i.e. the Certificate Usage
> >> field of the TLSA record). If I recall correctly, this should all be
> >> covered in detail in RFC 7671 ("DANE Updates and Operational Guidance").
> >>
> >> * With DANE-EE, only the EE certificate is matched against the
> >>   certificate data/hash in the TLSA record. There is no CRL/OCSP
> >>   style revocation. Revocation would be performed by removing the
> >>   TLSA record from the DNS.
> >>
> >> * With DANE-TA, the indicated CA certificate referenced in the TLSA
> >>   record may have advertised revocation mechanisms that need to be
> >>   consulted.
> >>
> >> * With PKIX-EE and PKIX-TA modes, the standard PKIX revocation
> mechanisms
> >>   need to be consulted and honored.
> >
> > Well, neither of these modes is useful here, as an attacker will simply
> ignore the
> > extension.
> Good point.
> Well, if a server publishes "CA constraint" (PKIX-TA(0)) or "service
> certificate constraint" (PKIX-EE(1)) TLSA records, presumably it is
> precisely because they believe that PKIX alone is not enough, and
> would like to require at least one of the specified constraints to
> be satisfied.
> So if the records do make it to the client, the client should
> probably honour them if it is doing DANE-based authentication.
> However, as you correctly observe, with this in-band TLSA record
> delivery mechanism, an attacker who is able to able PKIX-verifiable
> certificates and keys for the target domain can simply not respond
> with the extension and deliver just the PKIX key material.  So if
> a client is willing to go with just PKIX for servers that don't
> support the extension, then it subject to a "dane-stripping"
> downgrade attack when using this mechanism.
> We should also note that clients might cache the obtained TLSA
> records, and so might not accept just PKIX while cached records
> are available, even if TLSA records are stripped on a subsequent
> connection.
> But the key question boils down to whether the client is configured
> to *require* DANE for the connection (in which case just PKIX is
> clearly not enough), or whether it is doing a form of "opportunistic
> DANE" (for lack of a better term in this message) with the server
> optionally providing the records, but otherwise the client resorts
> to using just PKIX.
> In the "opportunistic DANE" case one might argue that, when PKIX-TA(0)
> or PKIX-EE(1) fail, but PKIX alone would otherwise succeed, the client
> should accept PKIX alone, since a downgrade attack can typically strip
> DANE.  But if the client is caching previously seen TLSA records, then
> the downgrade attack is partially mitigated (for the TTL of the cached
> records).  The client may elect to request new TLSA records before the
> expiration of the previous ones are expired, extending such protection
> until it stops communicating with the server sufficiently regularly to
> be able to keep a copy of unexpired TLSA records in its cache.
> So all in all, I think there may be enough merit in rejecting on DANE
> failure, subject to local policy, but the client might elect to trust
> bare PKIX.
> For clients that do reject PKIX success based on DANE failure, and
> cache obtained TLSA records, it might have been good to recommend
> refreshing the TLSA records while the cached data is still valid
> (say the smaller of some refresh time or 50% of TTL has expired).
> That way, for a client that keeps communicating regularly may be
> (partially) protected against downgrades.  Perhaps it is too late
> to make such a change at this stage in the document's life-cycle.
> Summary as I see it:
>   * Mandatory DANE:
>   MUST Refuse absence of TLSA RRs or failure
>     of PKIX-TA(0) and PKIX-EE(1).  Must fail when no TLSA RRs
>     are cache and the server does not present the extension.
>   * "Opportunistic DANE": MAY refuse failed PKIX-TA(0) and PKIX(1)
>     if caching replies, and SHOULD attempt to refresh cache before
>     expiration to reduce opportunity for downgrades.  Non-caching
>     clients don't really gain security by refusing valid PKIX on
>     DANE failure, and MAY choose to continue.
> --
>         Viktor.