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

Willem Toorop <willem@nlnetlabs.nl> Tue, 27 February 2018 15:47 UTC

Return-Path: <willem@nlnetlabs.nl>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D907012D969; Tue, 27 Feb 2018 07:47:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level:
X-Spam-Status: No, score=-7.01 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl
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 vxR2t5EMb1VC; Tue, 27 Feb 2018 07:47:27 -0800 (PST)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C8D126C22; Tue, 27 Feb 2018 07:47:27 -0800 (PST)
Received: from [IPv6:2001:980:2283:fe:e174:43b2:2b9b:795a] (unknown [IPv6:2001:980:2283:fe:e174:43b2:2b9b:795a]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id D55188723; Tue, 27 Feb 2018 16:47:24 +0100 (CET)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1519746444; bh=xFy8UV6F0JcfBQlAmOJ+N+S8M6/xmSjggJLaptecpDw=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=J7PKUFW6vjzJ6OYMW5Nm98zrgwC8bg/flI5zRa/88Cr17XTtQSMBvHcOtXJruCDJ4 XInuXcyYHXlzAUqlWsSIaTptcNdcGRbWA6u0zabnd5JZwV1GKNkL0A8/3vSwysePEV bXk4rt0cGJocdKZ24Eh8dQotejOfdAWjmUM0fBQw=
To: Viktor Dukhovni <ietf-dane@dukhovni.org>, TLS WG <tls@ietf.org>
Cc: draft-ietf-tls-dnssec-chain-extension@ietf.org, tls-chairs <tls-chairs@ietf.org>, The IESG <iesg@ietf.org>
References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> <CAHPuVdUgZLUf5M8ir=610mvERwQzPhbhGGOyW5s552JtP8d05g@mail.gmail.com> <CABcZeBOST2X0-MH2hhzpPJaUkbY++udsUV1bMnMhH2V2wQRPmA@mail.gmail.com> <CAHPuVdUs7mUJiqZjFjLDCNmHHGR9AP-g5YaLLbJj-zkDKd=_-w@mail.gmail.com> <alpine.LRH.2.21.1802211425260.7767@bofh.nohats.ca> <CAHPuVdX=_6b5g572-T-9Ccwek-WwL11KdTVwV9oNC9LaO5=0=Q@mail.gmail.com> <alpine.LRH.2.21.1802260913290.9977@bofh.nohats.ca> <9CE8B6BF-CAC0-46AE-B5FC-AF3D45EF9DBC@dukhovni.org> <56e66d4e-13c7-b2cd-e716-b86c12e50fe8@akamai.com> <9A433CB4-48B6-4CC2-9150-8C1FA629A3A9@dukhovni.org>
From: Willem Toorop <willem@nlnetlabs.nl>
Message-ID: <903d090a-2156-17e4-4b63-bb2374468c7d@nlnetlabs.nl>
Date: Tue, 27 Feb 2018 16:47:24 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <9A433CB4-48B6-4CC2-9150-8C1FA629A3A9@dukhovni.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/RfQhtcWkttmK1uraoL-znSnyPDw>
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Feb 2018 15:47:30 -0000

Op 27-02-18 om 16:12 schreef Viktor Dukhovni:
> 
> 
>> On Feb 27, 2018, at 9:34 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
>>
>> There doesn't seem to be much interest in pinning-like schemes for TLS
>> at this point (see also the "TLS server identity pinning" proposal from
>> the SAAG/secdispatch session at IETF 100).
>> And I do think the lack of authenticated denial of existence is
>> something the WG was aware of during our earlier discussions, so it's
>> unclear that there is a need to hold things up for this issue.
> 
> Awareness of is different from thinking through the full implications.
> I for one did not have the cycles to consider all the implications,
> and many others likely also focused on the data format, and may not
> have considered the use-cases with care.
> 
> Note that DANE-based "pinning" is fundamentally different from other
> "pinning" approaches, in that the client does not store the key
> digests for any significant length of time.  All it may do is
> cache the DANE TLSA records for a short time bounded by the DNS TTL.
> The digests that "pin" the server's (or issuing CA's) keys are managed
> in the server's DNS zone, and can be promptly updated by the server,
> and the client can learn of the change when presented with new TLSA
> records, OR as I now believe is essential for this specification to
> be at all useful, presented with authenticated denial of existence.
> 
> The only thing needed for denial of existence to be workable, is
> that the client cache a commitment by the server (a boolean value)
> to support the extension until such time as the server provides
> authenticated denial of existence of TLSA records.
> 
> This is much less brittle than client-side key pinning, with all
> its attended problems with stale data.
> 
> If this protocol has no denial of existence, I don't see any reason
> for anyone to deploy it.  Why publish something that's basically
> useless?

Well.. support of the option could be obligatory for new TLS services,
like DNS over TLS.  With DNS over TLS there is no user interaction
making third-party PKIX (i.e. a CA store) impractical.

Another possibility to authenticate DNS-over-TLS upstreams by clients,
is to setup the TLS without authentication, and then use that to do the
DANE queries over it (for privacy and to bypass hampering middle-boxes),
then authenticate the certificate and upgrade the connection to be
usable for all queries.  This works but is harder to implement and
causes a latency penalty because of the extra negotiations.

Note that the new initial draft (not WG yet) for encrypting the path
from the recursive to the authoritative, suggests DANE authentication of
the authoritative, and references the tls-dnssec-chain-extension draft
as the initial method -of acquiring the needed DNSSEC data- to try:

https://tools.ietf.org/html/draft-bortzmeyer-dprive-resolver-to-auth


Also, with DANE I like the fact that a DNS domain holder/owner can vouch
for it's own domain name instead of needing a third party.  And
although, opposed to DANE over DNSSEC, this extension doesn't add any
security, it still has that property.