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

Shumon Huque <shuque@gmail.com> Tue, 04 July 2017 16:36 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 04C56132346 for <tls@ietfa.amsl.com>; Tue, 4 Jul 2017 09:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 gotR52ukTUQS for <tls@ietfa.amsl.com>; Tue, 4 Jul 2017 09:36:00 -0700 (PDT)
Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 C94C913234A for <tls@ietf.org>; Tue, 4 Jul 2017 09:35:55 -0700 (PDT)
Received: by mail-ua0-x236.google.com with SMTP id g40so129615241uaa.3 for <tls@ietf.org>; Tue, 04 Jul 2017 09:35:55 -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; bh=lESfSVOFkHUmt2BfnHrRlR8ig2Bfl677MZOITijYWfk=; b=iY/+8mgLNuSeGgzS4Cx3l7PjgcO8IBDrl8LT/JgIZanYetIOE4p5W8Gj+weI7Gzd4c 1SyxYjxsVo1LPEryMKLhxtIwaHZFs0Dt/J9NNR4ihoQdpbClJZ7/m8MBF6FZjzqaoVjP PSOb6IHy5Dcwdk8/H5QSF9ChJwZlrHYoa6mKs6v19EqtDHmjc++EWKwGzFOG+/h86s5M hv3996ZQzOCrc9cEJlLnvpCffMQaVDSGkhq7Q/hc5s2FG4+LgvDrhwxHTGZmO6T4AAno Sl0JuPFv9+fLKfaTxb6tO1C5V+p3walOoQ28e+gJj/iaf/HWa1mBP80p89exQ4eJPYyi gSxg==
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=lESfSVOFkHUmt2BfnHrRlR8ig2Bfl677MZOITijYWfk=; b=CE62nPK8R6BzsVOX71g8FIBuKvkRDx3SADdci6UyVy1y7Iaryp9LTKHCqKixCljYnC kEzVUTHmgZ3RqReC2WblhdNvu2HS93FskSvoKb/1KfMNyACrLIdeBJ31EiSK3/j1O0NQ CHgPw2aho/JMwZYL6e5HDQ7iUi5OzQZWSse7Fwd1/BeVSmTAcsYRLW9F9XzW3G559KS8 aGybygWFqJSGfNW2K2u9nO8MUcq5mfHtexdT77AfW8GsU9OenXNDiUVgYNVP0bQQX3MC vSW+WYxEkFkLJqpIW8hzLegAoeH9dV1XjqD43dTgpZOx7RkRVk1rz8Sf35+Jj6FcPp+V eHrw==
X-Gm-Message-State: AKS2vOyyU+Ciyc3wLKPIFcrEdDi4+pDZ5QmhZJxLpIWF0ehOPgcII+Jx kw/9727fj6PyeQQn0prC+1nN/rD7nQUu
X-Received: by 10.159.35.169 with SMTP id 38mr21137718uao.20.1499186154789; Tue, 04 Jul 2017 09:35:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.79.231 with HTTP; Tue, 4 Jul 2017 09:35:54 -0700 (PDT)
In-Reply-To: <1861626B-4D85-4885-8377-3B0DF819E357@dukhovni.org>
References: <CAOgPGoAcuFF5v8f5LWpYQtgE8WygA+n1fsg0AeVFJX1=cADUgw@mail.gmail.com> <20170702140308.6amd5ds3qqt3ju5m@LK-Perkele-VII> <CAHPuVdWHaEjMQtjdRCS4cLVZW7iJ_urAcaE3DnWgWrwzC8d2Vw@mail.gmail.com> <1861626B-4D85-4885-8377-3B0DF819E357@dukhovni.org>
From: Shumon Huque <shuque@gmail.com>
Date: Tue, 4 Jul 2017 12:35:54 -0400
Message-ID: <CAHPuVdXXRZbWCgBOcqE-Vj5V2DPdCe7cx_S39N4mH9jT6Y10LA@mail.gmail.com>
To: TLS WG <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0402ea355eef0553807a5f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VxYq6PJh0cIgR6mD4eXBy1_xU-0>
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: Tue, 04 Jul 2017 16:36:02 -0000

On Tue, Jul 4, 2017 at 12:14 PM, Viktor Dukhovni <ietf-dane@dukhovni.org>;
wrote:

>
> > On Jul 4, 2017, at 11:33 AM, Shumon Huque <shuque@gmail.com>; wrote:
> >
> > Yes, in fact the previous sentence to the one you quoted did say this
> more or less: " ... return a serialized authentication chain in the
> Certificate message associated with the end entity certificate being
> validated ". I would propose rewording that a bit and removing the last
> quoted sentence entirely:
> >
> >    Servers receiving a "dnssec_chain" extension in the ClientHello, and
> >    which are capable of being authenticated via DANE, SHOULD return a
> >    serialized authentication chain in the extension block of the
> Certificate
> >    message containing the end entity certificate being validated, using
> the
> >    format described below.
>
> Why the end-entity certificate, and not the final certificate
> sent by the server?  With anything but DANE-EE(3) the TLSA
> records can't be processed against the server's certificate
> message until *all* the server certificates have been received.
>

I'm not in principle opposed, but intuitively it makes most sense to
associate the DNSSEC chain with the certificate being validated.

The other logical place this might have been placed is  Encrypted
Extensions. But that again precedes the Certificate message, so doesn't
address your buffering up concern.

Also if DANE-EE turned out to be the common use case, it helps right? Cause
the validator doesn't care about the rest of the certificate chain, and can
authenticate the EE cert right away.


> So instead of squirreling away the DNS data while waiting for
> all the server certificates to arrive, it may make more sense
> to receive the TLSA records (and associated signatures, CNAMEs,
> DNAMEs, ...) once all the server certificates have been received.
>
> Of course either way one still buffers all the server certificates,
> so buffering the TLSA records is not a major issue.  It's just that
> I don't see a compelling argument for sending the TLSA records with
> the EE certificate.  Perhaps send them with any of the server
> certificates, it probably makes no difference which...
>

Ok. Let's see if anyone else chimes in with opinions on this ..

-- 
Shumon Huque