Return-Path: 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: 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 To: Shumon Huque Cc: The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey , "tls-chairs" , TLS WG 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: References: <151802776446.4849.12008167318274714913.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2018 10:24:53 +0000 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 10:24:57 -0000 This is a multi-part message in MIME format. --_----------=_152085029323918720 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi, On Wed, Feb 21, 2018, at 4:06 PM, Shumon Huque wrote: > On Wed, Feb 7, 2018 at 9:05 PM, Shumon Huque wrote:>> On Wed, Feb 7, 2018 at 1:22 PM, Alexey Melnikov >> 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 --_----------=_152085029323918720 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
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> w= rote:
On Wed, F= eb 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 wi= ll ballot Yes once my small issues are resolved:

1) In 3.4:
   The first RRset in the chain MUST contain the TLSA record s= et being
   presented.  However, if the owner name of th= e TLSA record set is an
   alias (CNAME or DNAME), then it MU= ST be preceded by the chain of
   alias records needed to res= olve it.  DNAME chains should omit

SHOULD? What are the impli= cations 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 chai= n
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 s= ecurely 
validate the mapping and continue processing.

It might make things simpler to just make this a MUST. I would guess t= his
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 lo= oked
at what an existing DNS library implementation does, and it includes t= he
synthesized CNAME. It's easy enough for the client to just ignore it w= hen
validating the chain.

I think adding some text explaining this would be a good addition to t= he document.

Best Regards,
Alexey
--_----------=_152085029323918720--