Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

Martin Thomson <martin.thomson@gmail.com> Thu, 05 July 2018 02:31 UTC

Return-Path: <martin.thomson@gmail.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 C5312130D7A for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 19:31:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 N2_xKIgOmiTI for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 19:31:16 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 31F76130E1D for <tls@ietf.org>; Wed, 4 Jul 2018 19:31:16 -0700 (PDT)
Received: by mail-oi0-x230.google.com with SMTP id v8-v6so13922055oie.5 for <tls@ietf.org>; Wed, 04 Jul 2018 19:31:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7M7NkSZ+yMJ9xwcfzqM+CNnqDrTZRiLYWMR/FWi+8d4=; b=YWSM/wKcM+g4z8TVsPqkp8DM8N51rgbJldBDWMHHe6Yz3wSFQKMW7RJ1ZfGGARXbYe 86RcXbojIA/1JaLy2D9caJa213R3xtl+3LEt5+C2rX2PcKDCkUmtlu2JvnjG+YFocge7 MpHjlbRKj1BtYeq7FYOJmzlFKCi8d00alb/Kg796iJqq/kC5aYWIXIS12uuTHSx1GeZk kSmT+2nI1uEydfj/X4GcmrQAGUKobi+cmJSe+y8W0AcDP0qnZ4pnGZ7zna1903uhoaXK WADpGD661TGG2fVuKC+mc3UcDICcKjeLbQi3lihXdvLpyGEMtkRv8+jr0N7QiZ3jZtIN Bp4w==
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=7M7NkSZ+yMJ9xwcfzqM+CNnqDrTZRiLYWMR/FWi+8d4=; b=K4j/c51JZmYaq1odwrK7L3UU+lZ13MXN/lhpS8jvNTe0muq//QV7U+Qel3cYVMW7BT EoxgbwqOejRP+Beoi3J6oO2c2FJX1qasZ3uCnQdbpDZ1sRNzXkSs0eLmjt/3mD/cv1DF 0qsm7fy8YCIwmFAX+/r6VomNHID36veuoBB7VHtDCZhDxzgxKAMkPm2tN/JZk9KBLeC/ L28idLvYbvuwLZ/JE0HgYvQpQRd/RXBVwU9gdD57gZ0+/qQmqx/ZU/v2sJr3u7E6roRH THef4nrs8oRRBEJ+Qlhjjxpn4Lh9KIgyKk4iZynqkQfRep61pB9PVQcWQPHdK/Jblrkz Q5Bg==
X-Gm-Message-State: APt69E00U1nR/AZw3CV/ALtKCOw5y6xI6SZTfrCpVC6zewidPmTb2ujQ bSYBXF0cOCfgPporE0PRIVZRhbYYP/DDOJD4xVkLvQ==
X-Google-Smtp-Source: AAOMgpdQAsdiyuMdVn3rdU5FZ+ArLMYgnf7dvTKTefI/mSB697A5U5mXBe68X2501JMuHCJ/gm4H2z60hkREKfm0aWE=
X-Received: by 2002:aca:4e50:: with SMTP id c77-v6mr4361072oib.254.1530757875185; Wed, 04 Jul 2018 19:31:15 -0700 (PDT)
MIME-Version: 1.0
References: <20180604203947.GW13834@akamai.com> <alpine.LRH.2.21.1806050858340.8057@bofh.nohats.ca> <CAOgPGoBPfL46ogCGa4tSA2q9dikuTwrY766R5y3U-DD1k+XudQ@mail.gmail.com>
In-Reply-To: <CAOgPGoBPfL46ogCGa4tSA2q9dikuTwrY766R5y3U-DD1k+XudQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 5 Jul 2018 12:31:02 +1000
Message-ID: <CABkgnnVUa5DssuONuS+4xoO3bgu-kZsz_i4jU1ZmkpDZxwPpVw@mail.gmail.com>
To: Joseph Salowey <joe@salowey.net>
Cc: Paul Wouters <paul@nohats.ca>, "<tls@ietf.org>" <tls@ietf.org>, bkaduk=40akamai.com@dmarc.ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/naSCWZmodL-Yl27P3VbQDV3H0rQ>
Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
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, 05 Jul 2018 02:31:19 -0000

On Tue, Jun 26, 2018 at 2:21 PM Joseph Salowey <joe@salowey.net>; wrote:
> 1.  Do you support the working group taking on future work on a pinning mechanism (based on the modifications or another approach)?

I don't think that pinning is a good idea.  We've experience that
suggests that it's more of a footgun than a useful mechanism.  That
isn't to say that there isn't a domain where it makes sense.

> 2.  Do you support the reserved bytes in the revision for a future pinning mechanism?

No.  We need fewer extension points, not more.  It's already hard
enough to ensure that the ones we have remain usable.  ekr's
suggestion to reduce the number of *types* of extension point would be
a compromise position here, but I don't think that's the best outcome.

If we mess this one up, we can make another extension, or use another
extension to fix it if that makes more sense.  Yes, that's messy, but
the above assessment supports the notion that we won't need v2.

> 3.  Do you support the proof of denial of existence text in the revision?

Allowing denial of existence in the extension is fine.  It somewhat
depends on having a prior expectation of having some form of DNSSEC
record there, which hits all the concerns above, so I'm not sure what
concrete value it provides.  I see no harm in allowing it though.

> 4.  Do you support the new and improved security considerations?

I have to confess, I had a lot of trouble reading the new text.  It's
good, and contains much of what is needed, but it's very wordy.  I
think another iteration or two would help.

If I can summarize:

We consider the case where DANE is considered stronger than PKIX or a
valuable addition to PKIX, because this extension is only of use in
those circumstances.  If an attacker can compromise PKIX, then they
can just not send the DANE extension.  With prior knowledge, a relying
party might know to expect DANE, but that isn't always possible,
especially when this mechanism is introduced into a PKIX-only
ecosystem.  A relying party can't assume that use of DANE with one
connection implies that other connections to the same peer will also
be secured with DANE.

There's a lot of extra words around that message, and I fear that the
message will be lost as a result.