[TLS] Review of draft-asmithee-tls-dnssec-downprot-00

Martin Thomson <martin.thomson@gmail.com> Fri, 18 May 2018 06:43 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E8C73127241 for <tls@ietfa.amsl.com>; Thu, 17 May 2018 23:43:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 0SxTFGNvFkXs for <tls@ietfa.amsl.com>; Thu, 17 May 2018 23:43:04 -0700 (PDT)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 81E7012711A for <tls@ietf.org>; Thu, 17 May 2018 23:43:04 -0700 (PDT)
Received: by mail-oi0-x236.google.com with SMTP id e80-v6so6201216oig.11 for <tls@ietf.org>; Thu, 17 May 2018 23:43:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=7hukOtdTzp31Y590PsKnIAcxiecTv3iD6LkbU62S0qM=; b=D2N75lL/7ZlfXTjfLaHfiezq4PeghKyeTVcwF1/2vwFfhO5vGPPLnpOUBCMDl4VVla g8NDpRWdmyRa2wnbeNcUgR60CIczPONaDzerSbQjrCZd+x9bBnoujtEk3O1peqZItza9 3Rxc4DZHsmt0Q+Lk9q8fbq0cUC+f1KKPa1DlWfETfVLt1GAFN+V9pK2i/ynC95BuDK6i WDPof9Dt92W4fRAp1V0C8nbMV9tzShhD4VuAYMmFhcZq4W6dwR7MrhO8krPgkoAWOAYd G3Z3dpDzgh45uCS9HKSpe1eU4pz6w6uieZp6rGGjkIQHAQI6o+nDaCOsB9+uvmoImiSC hVKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7hukOtdTzp31Y590PsKnIAcxiecTv3iD6LkbU62S0qM=; b=LRVtokvqdyHLsTDvyEwawDpV+Jwv82n7VwUttQAKwASWvQBU+IPwGBsgsFETllNzW8 qr7pq64Z9mnDpey+w2EB9VfF/fYq8B7NPERMf0rlMXjO7xRTedZFrPe55GUSiy94ka9b xxYNWdbCTbBVXM7LnBvhp60VO8nqB3Nl0QVEV/61VZrrq7s8IuF0mF5/IlF8NwkdJkkI Rbjd+Jh9irdiHJZ8lY11u+EDL+qVfS6lRZFzcjLV1zzUZoe5SjHq6yODvftU1lI6QDfg yVItNmK4+Lg0OMfsiLf8+wRm9qwx7vFPMYCjp2CvOUX0Et5d9rnXkbDN6mA6yifZ0pjD E+SA==
X-Gm-Message-State: ALKqPwcqr429FAcjj/Fg+AoLHEa8fiQ6AKbNDJd6MHhxjZMqh9moyshZ jJ3ExiM7+nLiAzche1D3qsAFMYYAdo1VnbpfK2N079Bm
X-Google-Smtp-Source: AB8JxZpUVKsEefJydnCUchwKA4e0hHWsq5vq3m7hGu4wz8vhYJ7GWVgN6FoXQ0/OgYBRV5n1BszP0U8NzXvom65uBlk=
X-Received: by 2002:aca:ebd4:: with SMTP id j203-v6mr5296986oih.110.1526625783426; Thu, 17 May 2018 23:43:03 -0700 (PDT)
MIME-Version: 1.0
From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 18 May 2018 16:42:51 +1000
Message-ID: <CABkgnnVc_kR0OsO=DbYoA8vCe5sa24qOHRoPdH-ea2iU59t8tg@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fIc1TFLfcJ5qX6QdXZjvlt12d4o>
Subject: [TLS] Review of draft-asmithee-tls-dnssec-downprot-00
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, 18 May 2018 06:43:06 -0000

Hi Alan and Alan,

Thanks for writing this draft.  Even though the intent here is abundantly
clear and this email risks me being drawn into the toxic mess of the
related discussion, I found this draft to provoke an interesting thought.

Though the current design is for a two octet commitment that narrowly
addresses one particular extension, it seems that - like the must-staple
design - there is an opportunity here.

We have potential downgrade attacks on a range of extensions, not just the
identified one.  For instance, failing to provide the extended master
secret extension represents a fairly significant regression in capabilities
that could be indicative of an attack.  The same for renegotiation info,
SCT, and others.  I thought supported_versions might be a valid use, but
I'm not 100% sure there.  The extension could reference itself though.

A commitment to continue to provide a particular feature - as identified
via its extension - would be a potentially useful capability.

Of course, this would need to squarely address the potential for a service
to take itself out in the way that such commitments tend to.  It also needs
to address the scope of the commitment in more than just time.  This isn't
trivial when you consider that a server can be considered valid for
multiple identities.  The current draft doesn't really do either topic

Having this indicator expire when you get an authenticated denial of
existence seems odd.  Why not just update the lifetime when the connection
is successful unconditionally?

Finally, I don't see any value in the "if you use that then you must use
this" text in the draft, but that's likely just a consequence of the other