Re: [TLS] Alexey Melnikov's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

Alexey Melnikov <aamelnikov@fastmail.fm> Mon, 12 March 2018 10:24 UTC

Return-Path: <aamelnikov@fastmail.fm>
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 7B4EC126CC7; Mon, 12 Mar 2018 03:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Level:
X-Spam-Status: No, score=-2.719 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=eYt3tKld; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KpO9ZADJ
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 Y5SBNbVXH8Z0; Mon, 12 Mar 2018 03:24:55 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00CA0127275; Mon, 12 Mar 2018 03:24:54 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id AAC2D20D86; Mon, 12 Mar 2018 06:24:53 -0400 (EDT)
Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Mon, 12 Mar 2018 06:24:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=wB0t4ZkeiSK57ix+4Yq1m6cmyxDi0 0b7ZLVpGDuC8Y0=; b=eYt3tKldKfn7UdTabvCidhCjIb80K7Q8Ua9KPp4uvRbKe nuaWcg4hP3lG8picGn/8rc09La/euAJ7UdWgo3nUpIYK3OAhGY2N/JB5Xew8/c0P p7B8KQ82+t3A3HGx5iavJIz7usSLYSA1r23coUfx6/q45v0ipqwRQFwtQ0+g9XKQ rekHJqerDHfAVZ78svxAJQZHeRXE3wlZg809QoZCXLAeBhPvuLdi/7zxxFTeDZsS xa+uV9iKv/Q5MknzsjpAaBetdUffUxlI2zc/FqxJLkhdoLUC1rxu/VsxRzWNygST cDOuxJ7OVp9R/slEVr+jyKQ+HQtm7k/ZaFVYuWHFg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=wB0t4Z keiSK57ix+4Yq1m6cmyxDi00b7ZLVpGDuC8Y0=; b=KpO9ZADJurN3H1bLi8Pe95 C0U3CXyuq0ngyweTEtxNMSJ1sM0NzY4qMwzqkb1zIHIR5Gk3Beg+UmCd774fBxko +b68erboKsh5nH8r8V4D+/Nj9Y9s/gJbPq6l6mQRdg6PujTqiCmdmrZUmfkS7eDa f8J+BR9iDpYqMScaLuRcxBoxhB5pUKuP6Hbw8e7RXVNq988fpoZTNsqkWNCb3ZE/ yvRBjBToE0K+eEQ8FTMvqPT5FlTv5NYectt6yrNEJ/cWL1nGm62Zty6ihYqko2P/ S/jErZmEgibFBGz5iSjRjK2x5C3soqpzHOhgpBk9MykZ3OBt/I7//GkRhBMZjp+w ==
X-ME-Sender: <xms:dVWmWoqt7TUjpsh7O863RV1lHR_dehgMNR_g2uha_4MlHCyDgWChLA>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 85CA49E082; Mon, 12 Mar 2018 06:24:53 -0400 (EDT)
Message-Id: <1520850293.2391872.1299830624.0F7628AE@webmail.messagingengine.com>
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: Shumon Huque <shuque@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey <joe@salowey.net>, "tls-chairs" <tls-chairs@ietf.org>, TLS WG <tls@ietf.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_152085029323918720"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-54087d22
In-Reply-To: <CAHPuVdXF1j83r_4zRWc6pR7jB8LO9BWgj6KZv9FS52Fb+jj+8w@mail.gmail.com>
References: <151802776446.4849.12008167318274714913.idtracker@ietfa.amsl.com> <CAHPuVdUmPPFY2rxq0cdtwGaoDJ0Bkdt1PFsQmVm3Et5n9cU_Uw@mail.gmail.com> <CAHPuVdXF1j83r_4zRWc6pR7jB8LO9BWgj6KZv9FS52Fb+jj+8w@mail.gmail.com>
Date: Mon, 12 Mar 2018 10:24:53 +0000
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/hs8u4V6OoSmk3n8xo6SNqze4TZ4>
Subject: Re: [TLS] Alexey Melnikov's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
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: Mon, 12 Mar 2018 10:24:57 -0000

Hi,

On Wed, Feb 21, 2018, at 4:06 PM, Shumon Huque wrote:
> On Wed, Feb 7, 2018 at 9:05 PM, Shumon Huque <shuque@gmail.com> wrote:>> On Wed, Feb 7, 2018 at 1:22 PM, Alexey Melnikov
>> <aamelnikov@fastmail.fm> wrote:
>>> Alexey Melnikov has entered the following ballot position for draft-ietf-tls-dnssec-chain-extension-
>>> 06: Discuss
>>>
>>>  -----------------------------------------------------------------
>>>  -----
>>>  DISCUSS:
>>>  -----------------------------------------------------------------
>>>  -----
>>>
>>>  I think this is a useful document and I will ballot Yes once my
>>>  small issues are resolved:
>>>
>>>  1) In 3.4:
>>>
>>>     The first RRset in the chain MUST contain the TLSA record set
>>>     being presented.  However, if the owner name of the TLSA record
>>>     set is an alias (CNAME or DNAME), then it MUST be preceded by
>>>     the chain of alias records needed to resolve it.  DNAME chains
>>>     should omit
>>>
>>>  SHOULD? What are the implications if this is not followed?>> 
>> Ok. I guess we need the upper case word here, yes.
>> 
>> Implication: If the synthesized CNAME records are included in
>> the chain>> then the client will have to ignore them (they aren't signed and thus
>> can't be>> validated) - the signed DNAME record is sufficient for the client to
>> securely>> validate the mapping and continue processing.
>> 
>> It might make things simpler to just make this a MUST. I would
>> guess this>> would not raise any objections from the working group.
> 
> A quick follow-up on this. I think we just keep this as a SHOULD.
> I looked> at what an existing DNS library implementation does, and it
> includes the> synthesized CNAME. It's easy enough for the client to just
> ignore it when> validating the chain.

I think adding some text explaining this would be a good addition to
the document.
Best Regards,
Alexey