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

Benjamin Kaduk <bkaduk@akamai.com> Fri, 07 July 2017 15:59 UTC

Return-Path: <bkaduk@akamai.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 CF98D131609 for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 08:59:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 2Ma89PIpBTjr for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 08:59:29 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9A912EC0D for <tls@ietf.org>; Fri, 7 Jul 2017 08:59:29 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v67Fv4bt002691 for <tls@ietf.org>; Fri, 7 Jul 2017 16:59:27 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=HZKRqfyYEuFUSAQ4x3GcE2SP6u44b20zwQ29GzeGs/U=; b=TZM8mP+popF9COQIqtF2V+GeU6n6NBfSuVYEN3G8IyKtAyq8RtLaMESnqODsTI/CX4iV tFXcAowbgy6uHHPrHl7eru53bzj1bK6+grN21XUOH1j5ctNUHKkUD5dVw0Vc4eiY6VJZ 9wIPNgnwren67/ARF8UGQeRm0yRS8L7hxfPQGA6W5+zLcAJWweEZZwqZPWLcdVuY3aV8 IHyRJQBBRqLcCKotBRez7938riawJq0N4QSoH1EqMBDKjOHa1KUM+G+fbxbUpPe/MgQp yxBgmlNGCZH+8o/azD0CXTo+aRJnRGAYPqBoQ8823xidURhzCMAz+qvav1TJYJ1l9uHk 6w==
Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2bhjxwe80v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tls@ietf.org>; Fri, 07 Jul 2017 16:59:26 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v67Fu0RE018971 for <tls@ietf.org>; Fri, 7 Jul 2017 11:59:26 -0400
Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint1.akamai.com with ESMTP id 2be72ug697-1 for <tls@ietf.org>; Fri, 07 Jul 2017 11:59:26 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id DDC501FC7B for <tls@ietf.org>; Fri, 7 Jul 2017 15:59:25 +0000 (GMT)
To: "tls@ietf.org" <tls@ietf.org>
References: <CAOgPGoAcuFF5v8f5LWpYQtgE8WygA+n1fsg0AeVFJX1=cADUgw@mail.gmail.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <e85e25dc-cad4-9339-87bc-9491e13ce398@akamai.com>
Date: Fri, 07 Jul 2017 10:59:25 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CAOgPGoAcuFF5v8f5LWpYQtgE8WygA+n1fsg0AeVFJX1=cADUgw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------0CCB580A1061DDD801708ED4"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707070265
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707070266
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/E1glbtbrLgre6W3suM2ufAqcSYo>
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 15:59:35 -0000

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?)

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