Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS

Ted Lemon <mellon@fugue.com> Tue, 16 October 2018 08:33 UTC

Return-Path: <mellon@fugue.com>
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 7CC4B12D4EE for <tls@ietfa.amsl.com>; Tue, 16 Oct 2018 01:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 WssVE_efUzm4 for <tls@ietfa.amsl.com>; Tue, 16 Oct 2018 01:33:26 -0700 (PDT)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF1012D4EB for <tls@ietf.org>; Tue, 16 Oct 2018 01:33:26 -0700 (PDT)
Received: by mail-qk1-x733.google.com with SMTP id q5-v6so13578725qki.6 for <tls@ietf.org>; Tue, 16 Oct 2018 01:33:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oD7tPpPP8fqC0KxCbsQlxjTzisF0DHcoJ02vuarZB58=; b=yMXZTDeNWPi8M3QVgnNrk0wTAsC/mALEVr307ffOhT4FqO+kNalbCNz9bayGLi4cTZ Kx+0nYX4mzQ+TTLMMWJpTE6IQd4OCth4OQM0do7MDfLRdlTS4k53fX08CWS8GxC40LzD K9ZA5W++yRGc1p19lYoBIhUy1NpHDl1M8+87fpmkW0aSg32vaLx4SMarLYqvPUrx0cSr gTqZ5vuS/fQTPC4OQwpUEooRGyrKX92PaekIK74SSBeU9z4HSjFWI3RcG2LuyS87xmil 5Pv/6dlBUQ+8ICmDMD2depoQFjnuYimjP5QlasOAWbwHX8/QmEwAwPZXSayN7Ri6bita NVew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oD7tPpPP8fqC0KxCbsQlxjTzisF0DHcoJ02vuarZB58=; b=VYn/HC4pSWL3xnURdFw9gwtaTsggfT5y15SRl+p3A5vmx/0GPlDaOw5y0+STDjGgAo pRXtbOwgs5XTkpxinikjTkrMa/+TthOAOQjTMFH4nQrnvP9PWGZGJfpix9vU+yU0C59J m/I2cvRAPWkPnyZJ+VjrrNIsHuDzAQ0Pmm5JKofctX0rbJDs9cIPttHwfu4//QgQvUWQ 2AEpK6QxyhyZeiwBAhe4yEgETSw6briIs7sKURpalNRYnYzu8kyIQWUKK6LD4FKara2r gmy4/LrtY4O4rgiLCCv/XPb57kyhFCjpT052LcqIWizZyvdFvMt1F+e5S30DB1ZrJC0R lCiw==
X-Gm-Message-State: ABuFfohUCFXVh2wLJmpm5Ql9pMlwYOchvf9BaiuOzkuZ61m3KTn0SmNu 5HhttcA97MnOjkIdm1QsI1mix/p879P2NlW8Bzqf0/A6QK4QeQ==
X-Google-Smtp-Source: ACcGV62fD56CKHGeE7obIL8Pz5VaJ3dpwm00fH0fp8T7K451im2WAzOEmMQu+obJHiaFFccWWDDxevkmZzM/iSe/zig=
X-Received: by 2002:a37:bf46:: with SMTP id p67-v6mr20072077qkf.46.1539678805493; Tue, 16 Oct 2018 01:33:25 -0700 (PDT)
MIME-Version: 1.0
References: <90e2851e-6469-226c-b2bd-63efebdfd796@bartschnet.de> <9700FD81-5DDF-4A14-B740-1216A749510D@dukhovni.org> <CAErg=HGiOMYnFFpkd1NKZP6hcTuSdEEOCdGKQZBp5oNP=CkNOQ@mail.gmail.com>
In-Reply-To: <CAErg=HGiOMYnFFpkd1NKZP6hcTuSdEEOCdGKQZBp5oNP=CkNOQ@mail.gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 16 Oct 2018 10:32:49 +0200
Message-ID: <CAPt1N1=6PdpxR8nLDx66ErY_hLTf_N-pZvH70kaNepfNm7Uz4A@mail.gmail.com>
To: ryan-ietftls@sleevi.com
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000451cdd0578546883"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/B_S3bwsRyUR9BHpiDrh1liev3BQ>
Subject: Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS
X-BeenThere: tls@ietf.org
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." <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, 16 Oct 2018 08:33:30 -0000

Not an argument in favor of the proposal, but the issue with firewall certs
is not that we would want to override local security policy, but that
firewall certs *can* in principle override local security policy, and in
principle DANE could be used to prevent that.   What is meant by a firewall
cert is a cert that's able to sign for any domain; such certs can in
principle be obtained by entities other than the operator of the local
firewall.   We're calling them firewall certs because that's the ostensible
reason for their existence, but we shouldn't assume that the name has any
power to restrict how they are used. :)

On Tue, Oct 16, 2018 at 3:45 AM Ryan Sleevi <ryan-ietftls@sleevi.com> wrote:

>
>
> On Mon, Oct 15, 2018 at 4:50 PM Viktor Dukhovni <ietf-dane@dukhovni.org>
> wrote:
>
>> Though I am generally an advocate for DANE, and have done much work to
>> further its adoption, this is not a realistic proposal.  DANE adoption
>> in TLS will be incremental and will not be accomplished via a mandate.
>>
>> > On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. Informatics
>> <ietf=40bartschnet.de@dmarc.ietf.org> wrote:
>> >
>> > TLS is prone to Man-In-The-Middle attacks with unjustly obtained
>> intermediate certificates (e.g. firewall appliances).
>> > The DNSSEC KSK-rollover worked like a charm.
>> >
>> > So I suggest to make DANE-TLS mandatory for TLS to prevent
>> Man-In-The-Middle attacks with unjustly obtained intermediate certificates.
>>
>
> I think there's another criticism to be leveled at this proposal, and it's
> suitability for this WG - the motivation stated (firewall appliances) is a
> question about local policy. I admit my own ignorance here, in that I'm not
> sure how https://tools.ietf.org/html/draft-nottingham-for-the-users has
> been progressing as a comparable alternative to the HTML Priority of
> Constituencies. However, as engineers, we need to recognize that no matter
> what is memorialized by the IETF, if you have control over the machine - as
> these enterprises inevitably do to install their firewall appliance - all
> bets are off. We should not pretend we will prevent that, nor should we
> increase costs for the ecosystem in pursuit of that effort.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>