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

Eric Rescorla <ekr@rtfm.com> Thu, 12 April 2018 23:11 UTC

Return-Path: <ekr@rtfm.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 4C9FF12422F for <tls@ietfa.amsl.com>; Thu, 12 Apr 2018 16:11:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 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_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 Extw3gdE3apk for <tls@ietfa.amsl.com>; Thu, 12 Apr 2018 16:11:09 -0700 (PDT)
Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (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 1A61512421A for <tls@ietf.org>; Thu, 12 Apr 2018 16:11:09 -0700 (PDT)
Received: by mail-ot0-x22d.google.com with SMTP id o9-v6so7929475otj.5 for <tls@ietf.org>; Thu, 12 Apr 2018 16:11:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=mQCAs/b8sU8vt1VG1uYx/WwbAyyFdu7ypsIzqS3tNbQ=; b=p+qea0IwP5ODE7iXVzBj44XcH7ZAlkQDL2keepBjEuLEbx1S4RAFBb4b1cijHN7ubq Mkw+f0HvQmuRrRO1W+BIg8SCGtLs7HQGKtewjeGRva3BTYRNbup4bBR6NPHrrz2RDYGk bYLO/htSnyZBg2JsG4UgZ2yu9bpda746VDCrqJdBXp0y9Iv9Z9V2Qscg320ZApRpcA4M bBXgT41+CMhHOjrfO4Rs1PIEtZTraY4B72FQc8MyREamvfyTRcv8D9oIM27pzgPq5Ssv o1m4HEf7EX+K8vEu1o1krsKVh1etGsPWsmCBn8YjPNffZZK2ZF/xsvqBmqfxZK8KEuum wdzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=mQCAs/b8sU8vt1VG1uYx/WwbAyyFdu7ypsIzqS3tNbQ=; b=dMlU7uhrtsuuWbXO2hEnuHo/A4zForw8tHOHnaac98QCgQdAYwxvj7VgaKNgY1kAwW F8lB9TLp2ZncXdMGNwzIYdllhwL0y9lZ6GfW2CJXwhhjrCojjbLsI5dUDXTY1vjrvWQH Oan9MAiesgJG4ns7UVrOLbyq6hkxa5cj8YHDPX/+JwiG+y7XPjZy6SSe5Ssw31lc4I0l CbGMsk7WXkuyhRmBVrspIm61cxw/lpYQmqRGMb9NQNsd++X1b9ROL0LFha7BoNQJab7x RUgdBQWGIeWu+VP4udPfGwN5uuKcKF1Tm+NZylnitX7AuuvIX9KzTSWRjKouibd9uSHU 39kw==
X-Gm-Message-State: ALQs6tDCO16EfziwoZqa3MoZBt0D1bx3IYll5TT+Et6+Bmmku1SwToz+ xy3hRH6ifhaMIi0T7CjhjZoE577Q5yCRC5D5banBGgAs
X-Google-Smtp-Source: AIpwx4+gv8/+mIeq/FxqMOZZzrdmn//AubnZXBSvBQYr3XU4RpVBOjaMI7Dhl2ajYy/GefBh1gmIX8S/MCNUZpDvr64=
X-Received: by 2002:a9d:e06:: with SMTP id c6-v6mr2181071otc.371.1523574668349; Thu, 12 Apr 2018 16:11:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.138.18.130 with HTTP; Thu, 12 Apr 2018 16:10:27 -0700 (PDT)
In-Reply-To: <E3918F11-9AD7-4C06-9173-5175ECACD16B@dukhovni.org>
References: <CAOgPGoAhzEtxpW5mzmkf2kv3AcugNy0dAzhvpaqrTSuMSqWqfw@mail.gmail.com> <CAHPuVdXfVQ5ZYL+dTvFeTfOaz2NNPrqxvnWuqJkxu0aaKDF_Sg@mail.gmail.com> <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <alpine.LRH.2.21.1804120438460.24369@bofh.nohats.ca> <CAL02cgSuTOaT_NwnpXaa8DPhNJhzqZwepRL+J29BzcBfCTDtHw@mail.gmail.com> <CAHbuEH78KNyk8fnHThRkCERKPjZzYppi1uhkDx6kL_t448q0_g@mail.gmail.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <CABkgnnUwOjkY1_KejV-YOw3YRqjFfzaYurEY1OpZ8phQVhcWLg@mail.gmail.com> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> <aa7ca33a-4acd-c770-a43c-df7a1f66c782@nlnetlabs.nl> <E3918F11-9AD7-4C06-9173-5175ECACD16B@dukhovni.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 12 Apr 2018 16:10:27 -0700
Message-ID: <CABcZeBP6-7_NNmC+7iVnNXbQw7p3jJH4eC1-EjY4C4CwdWWNcg@mail.gmail.com>
To: TLS WG <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e56ac60569aede84"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Oz9wRRvBUeySJOaDwAIsAlM2hTU>
Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
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: Thu, 12 Apr 2018 23:11:11 -0000

On Thu, Apr 12, 2018 at 4:06 PM, Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:

>
>
> > On Apr 12, 2018, at 6:44 PM, Willem Toorop <willem@nlnetlabs.nl> wrote:
> >
> > Well... I find it unfortunate that the line you were quoting from
> > section 3.4 could be interpreted as prohibiting the possibility of
> > denial of existence.  So I am open to relaxing that text so that it can
> > not be interpreted as such anymore yes.
>
> Current text:
>
>    The first RRset in the chain MUST contain the TLSA record set being
>    presented.  However, ...
>
> Proposed text:
>
>    When the server has DNSSEC-signed TLSA records, the first RRset in
>    the chain MUST contain the TLSA record set being presented.
>    However, ...
>
>    When the server either has no TLSA records, or its domain is not
>    DNSSEC-signed, it is RECOMMENDED that the server return a denial
>    of existence of either the TLSA records, or proof of insecure
>    delegation at some parent domain, rather than omit the extension.
>    Clients that are willing to fall back from DANE to some alternative
>    mechanism may require the denial of existence to make that possible.
>

I believe that that this text would harm ineteroperability.

The difficulty here is what the server knows about the clients behavior.
Specifically, if the server serves TLSA records and then ceases doing
without serving authenticated denial of existence, then it is unable to
determine if this would cause clients to fail because it doesn't know if
the client implements the text in the final paragraph. One could argue
that current clients could pin, but that's totally extratextual, as opposed
t having a noninteroperable behavior in the document.

-Ekr


> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>