Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04

Shumon Huque <shuque@gmail.com> Fri, 07 July 2017 18:31 UTC

Return-Path: <shuque@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 410471317CE for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 11:31:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 UpwxgDn62A-b for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 11:31:11 -0700 (PDT)
Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 BB8D5131698 for <tls@ietf.org>; Fri, 7 Jul 2017 11:31:10 -0700 (PDT)
Received: by mail-ua0-x22b.google.com with SMTP id g40so25109257uaa.3 for <tls@ietf.org>; Fri, 07 Jul 2017 11:31:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SSD6KJav+ubG+ocfaqpzYidggTY1aEAbz5vvdZmQnxY=; b=pHCvkfsrFPEuZ2iGVIXesOUB8dymOHbqRjnZe37Q7kAzLCDmDxTqKCEo7uMxc/cLvR G3CM2NSRtbkJyX+Lv1eYvH5zdw9i5uGaheBYerU1VvaGADZFXA6EW+f5be0MxKToc9sO KFrMZHLBPpKr3B6UIms/gxwMH8iMRIyymiQv0eBRoE5YokDqFC91PdSb9EzlLwkYzUix MlzPnhYB00oNVlUApd4ckKJqB3CVxqvDvjS463I0Wrqjx7zrY+R9Acb2qfZutIvrvVhr ZWx78KUmY6xhPNu3M9SDkWehZJ/rRnbmDZ5OOtgLvwQQjMe51+1I3zoxWWE9Gc9TNNS0 lhuQ==
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:cc; bh=SSD6KJav+ubG+ocfaqpzYidggTY1aEAbz5vvdZmQnxY=; b=TnSVidME2J64AhOd+NkYS2cD0PynpNBo0FsJ5Apy29hdYCqSJ/Frv/61xA46g1RF45 b+HD9gsrwqZhWPU8Zj3Y/K/HSPxHtr01xkbj03ofK4FjzlkeNw+D40NHn+pNqnFyCfOm zQ52SGceAY6u5DVo/jErnBvhUeLdjh8c5ol4TWF7XCjh9WMwaZ2yhizYsI/oYATm1sLZ uFHL9TqbJ46W626LfmVYnePdPbTWuBW4EWWD9GDMdANJFMzO07RoBPWNbHVGNjWk3iyh YJ4wyBawbD3wyU3Lo6zler0Sy5/Y9U+9a95CffpVOGalJ8eRXkyrkIg1K1srXCvc51y1 8BkA==
X-Gm-Message-State: AIVw110etVrkrJN955LEO8RqxKulabJBqwx2jK+CBxqqgAOv4oTQOL+h w6nsO8V/TnqMex64sXOeNjyag/AsPg==
X-Received: by 10.176.86.21 with SMTP id y21mr1341967uaa.72.1499452269875; Fri, 07 Jul 2017 11:31:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.79.231 with HTTP; Fri, 7 Jul 2017 11:31:09 -0700 (PDT)
In-Reply-To: <e85e25dc-cad4-9339-87bc-9491e13ce398@akamai.com>
References: <CAOgPGoAcuFF5v8f5LWpYQtgE8WygA+n1fsg0AeVFJX1=cADUgw@mail.gmail.com> <e85e25dc-cad4-9339-87bc-9491e13ce398@akamai.com>
From: Shumon Huque <shuque@gmail.com>
Date: Fri, 7 Jul 2017 14:31:09 -0400
Message-ID: <CAHPuVdU90P9tJ1h03btpj=aDt0OORYhMHB0o4wCAZwo3isn1oA@mail.gmail.com>
To: Benjamin Kaduk <bkaduk@akamai.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="f403045dd5b0e755b20553be6f44"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fJAWPZNgaQI67t_WEsqtGlvdgzM>
Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04
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: Fri, 07 Jul 2017 18:31:13 -0000

On Fri, Jul 7, 2017 at 11:59 AM, Benjamin Kaduk <bkaduk@akamai.com>; wrote:

> On 06/28/2017 04:15 PM, Joseph Salowey wrote:
>
> This is the working group last call for draft-ietf-tls-dnssec-chain-extension-04.
> Please send you comments to the list by July 12, 2017.
>
>
> Just a couple minor things I don't remember being mentioned already that I
> noticed in a quick read:
>
> When section 3.4 mentions that "this document describes the data structure
> in sufficient detail that implementors if they desire can write their own
> code to do this", it seems that this really on makes sense when the "this"
> is for the encoding side, not the decoding side.  That is, in that we
> expect future DNS clients to continue to process responses in the current
> format, but future DNS servers might generate responses that cannot be
> properly decoded just following this document.  (E.g., what would happen if
> NSEC5 became popular?)
>

I think it's best to take that sentence out. It's a remnant of much earlier
versions of the draft where we did describe the decoding (and validation)
side in more detail, whereas now a lot of the client side processing is
being referred to DNSSEC specs.

Regarding future DNSSEC protocol enhancements that may necessitate format
and protocol processing changes, maybe it's best to defer those to future
revisions of the spec. But feel free to propose any specific wording on
this topic for inclusion.

(NSEC5 adoption in DNSOP is still very much an open question. The other
possible enhancement that might need to be considered in the future is
records related to key transparency - "CT for DNSSEC", which could happen
someday.)


> In section 8:
>
>    Mandating this extension for Raw Public Key
>    authentication (where there are no X.509 certificates) could employ
>    configuration mechanisms external to the TLS protocol
>
> this sentence structure is a little confusing; it might be better to say something like "If needed, configuration mechanism external to the TLS protocol could be used to mandate the use of this extension for Raw Public Key authentication".
>
> -Ben
>
>
Yes, your suggested text sounds much better. We can incorporate that.

However, there is larger concern that I have with section 8 that probably
deserves working group discussion. This section might imply that there is a
(protocol resident) way to mandate the use of this extension, but I don't
think there is an easy way. Even in the case of X.509 certificates, the TLS
feature extension can only dictate the delivery of this extension when the
client has connected to the right server presenting that certificate.

A TLS client misdirected to a rogue TLS server (e.g. via DNS spoofing, a
routing attack, or other means) that has fraudulently acquired a public CA
issued certificate for the legitimate server name, could be induced to
establish a (PKIX) verified connection to that rogue server that precludes
DANE authentication, when in fact it was available.

Some TLS applications may desire to mandate DANE authentication where
available, and protect themselves against malicious or tricked CAs. What is
the best way to accommodate them? TLS clients could keep a whitelist of
DANE servers, which doesn't scale very far; they could use TOFU/HPKP like
methods: add DANE supporting sites to a whitelist dynamically as they are
seen, etc.

Some other applications use the presence of an authenticated TLSA record to
enforce DANE authentication (RFC 7672 for SMTP STARTTLS). The last time
this was discussed in the context of tls-dnssec-chain, it was argued that
this "mandatory use" was not a semantic that the generic TLSA record
provides, so only specific applications should specify that behavior. But
if a specific TLS application using this extension did want to specify this
behavior, how could it happen?

In a hypothetical world where all TLS clients & servers understood this
extension, we could have required the TLS server to either (1) present the
dnssec_chain for their TLSA record, or (2) present a dnssec_chain that
demonstrates that there is no secure TLSA record, or that there is no
secure delegation to the zone. I think this would solve the problem, but
this isn't practical any time soon (or perhaps ever).

I'm not suggesting that we need to come up with a solution for this, but I
believe the issue probably needs some sort of mention somewhere (in
Security Considerations?).

-- 
Shumon Huque