Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-vectors-06: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Wed, 25 July 2018 15:08 UTC

Return-Path: <kaduk@mit.edu>
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 B4943126CC7; Wed, 25 Jul 2018 08:08:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 vfG0JhhPVTPC; Wed, 25 Jul 2018 08:08:10 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 5F5EC129C6B; Wed, 25 Jul 2018 08:08:10 -0700 (PDT)
X-AuditID: 1209190f-ea5ff70000006382-a3-5b58925965af
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id F4.9D.25474.952985B5; Wed, 25 Jul 2018 11:08:09 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w6PF86Ov008211; Wed, 25 Jul 2018 11:08:07 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w6PF81EY029950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Jul 2018 11:08:04 -0400
Date: Wed, 25 Jul 2018 10:08:02 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Mirja Kühlewind <ietf@kuehlewind.net>
Cc: The IESG <iesg@ietf.org>, tls@ietf.org, sean@sn3rd.com, draft-ietf-tls-tls13-vectors@ietf.org, tls-chairs@ietf.org
Message-ID: <20180725150802.GS92448@kduck.kaduk.org>
References: <153252913753.15442.1592178172017620793.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <153252913753.15442.1592178172017620793.idtracker@ietfa.amsl.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsUixG6nohs5KSLaoPuigMW8HfPZLWb8mchs 8eL6R2aLK6samS3mnLjBYvHpfBejA5vHkiU/mTxaPi5k9Th4kDGAOYrLJiU1J7MstUjfLoEr 43f3VMaCXv6Ki7fOszUwbufpYuTkkBAwkXh79CNjFyMXh5DAYiaJuUuuQDkbGSVety1ggXCu MknMP/aAEaSFRUBV4sSZ22wgNpuAikRD92VmEFtEwEbi7sm7rCA2s0C9xM/1LWDNwgIzGSWe ft0HluAF2tdwbD87iC0k4CtxfNYMJoi4oMTJmU9YIJp1JHZuvQO0gAPIlpZY/o8DIiwv0bx1 NtguTgE/iaNf2sFsUQFlib19h9gnMArOQjJpFpJJsxAmzUIyaQEjyypG2ZTcKt3cxMyc4tRk 3eLkxLy81CJdE73czBK91JTSTYygSOCU5N/BOKfB+xCjAAejEg/vB7vwaCHWxLLiytxDjJIc TEqivEGeEdFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHhdDgOV86YkVlalFuXDpKQ5WJTEee/V AKUE0hNLUrNTUwtSi2CyMhwcShK8zhOBhgoWpaanVqRl5pQgpJk4OEGG8wANLwCp4S0uSMwt zkyHyJ9i1OX4837qJGYhlrz8vFQpcd5QkCIBkKKM0jy4OaAEJpG9v+YVozjQW8K8ZycAVfEA kx/cpFdAS5iAlogmh4IsKUlESEk1MFabtXwLMpnXsabPpUig6smDr0bzTHc9PJC/Rp9v1Wou x5kLxTPXlF5SjX4Rv+SlePbBjVcX/BCacuR6tvQBy9gZ88pybveG2Bz6Hj6n+fXjC8JyHO7b s4q5d3H5e59S4n5jebxKqKXCZlF5+6cOnx8KIt6lj3yTPpfvfvT+rcWuj1tLo+alKCuxFGck GmoxFxUnAgDiJzfzOwMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/4iSnPkKWbKnBLTfQVaEAfmwSpZ8>
Subject: Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-vectors-06: (with COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.27
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: Wed, 25 Jul 2018 15:08:13 -0000

On Wed, Jul 25, 2018 at 07:32:17AM -0700, Mirja Kühlewind wrote:
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-tls-tls13-vectors-06: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Why is it really necessary to publish the test vectors in an RFC?

Well, hopefully we can avoid being caught in a catch-22.  That is, a lot of
the time when processing-heavy (especially crypto-heavy) documents come
through, we ask for test vectors at IESG review if they are not already
present.  So in the case when the base document is already long, it seemed
pretty natural to keep the test vectors in an adjacent place and the same
format, just as a separate document to keep the individual document sizes
down.

So, I'm generally of the opinion that it's better to have test vectors than
to not; it provides concrete guidance in the case when the wording of the
spec is potentially unclear and it helps new implementations develop
interoperability during development instead of being presented with a vague
"it doesn't work" once all the pieces are implemented.  We could certainly
debate what the best place for documenting the test vectors is, but I think
there is both precedent and a reasonable set of advantages to including
them in the RFC series.

-Benjamin