[TLS] Terry Manderson's Yes on draft-ietf-tls-tls13-26: (with COMMENT)

Terry Manderson <terry.manderson@icann.org> Wed, 07 March 2018 06:15 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Terry Manderson <terry.manderson@icann.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tls-tls13@ietf.org, Sean Turner <sean@sn3rd.com>, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152040333117.17585.16354330927450532201.idtracker@ietfa.amsl.com>
Date: Tue, 06 Mar 2018 22:15:31 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/gqKKmrB7_qHKhxOkMSj1TRLgkFg>
Subject: [TLS] Terry Manderson's Yes on draft-ietf-tls-tls13-26: (with COMMENT)

Terry Manderson has entered the following ballot position for
draft-ietf-tls-tls13-26: Yes

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/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you (Editor, Work Group, and all the contributors) for an exceedingly
well written document, pragmatic structure, and meaningful appendices (esp
Appendix E.5 for 0-RTT).

As a _very_ loose comment that can't really be actioned at this step; I like
the various 'handshake' tables however the some of the follow-on paragraphs
used to describe packets required a second read to understand. I guess it's a
stylistic preference and I'll leave that for the draft editor and RFC Editor to
look at in due course (so please don't respond to this particular comment but
expect time in the RFC ed process clarifying for the neophyte)

Can some of the subtle text be made a little tighter? (only if your AD believes
it worthwhile) For example in section 4.2:

it is written:
"Some cases where a server does not agree to an extension are error
      conditions, and some are simply refusals to support particular
      features.  In general, error alerts should be used for the former
      and a field in the server extension response for the latter."

I think what the WG is trying to say:

"In general, error alerts should be used where a server does not agree to an
extension and it is an error condition. When it is a refusal to support a
particular feature a field in the server extension response should be used."
(all with lack of RFC2119 language)

(..interestingly the bullet following the above is very clear)

Really nice plan to use 0x7f00 as the draft version indicator.

Thank you for dealing with padding as you have. Much appreciated!

[TLS] Terry Manderson's Yes on draft-ietf-tls-tls… Terry Manderson