IETF Logo Mail Archive

[TLS] Editorial: chronological order in ECH draft

Carrick Bartle <cbartle891@icloud.com> Wed, 23 June 2021 23:05 UTC

Return-Path: <cbartle891@icloud.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 3ED073A12FA for <tls@ietfa.amsl.com>; Wed, 23 Jun 2021 16:05:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 Mbm7y_zjLEa2 for <tls@ietfa.amsl.com>; Wed, 23 Jun 2021 16:04:56 -0700 (PDT)
Received: from mr85p00im-zteg06021501.me.com (mr85p00im-zteg06021501.me.com [17.58.23.183]) (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 91DC53A12FC for <tls@ietf.org>; Wed, 23 Jun 2021 16:04:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1624489496; bh=5PfiP1H+E7JAVv3+q/h5+hZFHmRBGi0K0AEKeOL8EWM=; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To; b=T1e8FC2cSWMwWRFUVvjsthJUBz84x+26pjMs8+q1vuAWSbKK2ZKQsN4/M+MYgnC1G CVkosx7QtDjqbY50o9UxiJcQLaKUcyjkuCEaut7kn+ys5qiJVHqYQ4LZlpOLRcG31O DYpruHvbXXemRIgZxZ0a1v/9hfoPj2N0wMjSu0Np0CVJtu0tXdo3yqWR771G6o72hh +VJSFqgqWRYmVdViQoD8oFHOqeWdnsGkgkAoY0jlV6Xg0f/ntHMDyo9qZc0HjFfJHA uvSUJEny503smguO14WUN6i0lu4yWnJtlGF91bax05W7NXfmxFagRCHGIoVU4ZBOZ8 8+sN2j0XJ8xGA==
Received: from smtpclient.apple (unknown [17.234.99.203]) by mr85p00im-zteg06021501.me.com (Postfix) with ESMTPSA id 7AC3438040A for <tls@ietf.org>; Wed, 23 Jun 2021 23:04:55 +0000 (UTC)
From: Carrick Bartle <cbartle891@icloud.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2E3A4FC4-59F1-42C2-AC69-99EB6088FCFC"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
Message-Id: <363384B1-7CB7-45FC-9FDF-7F8D08B80E81@icloud.com>
Date: Wed, 23 Jun 2021 16:04:54 -0700
To: "<tls@ietf.org>" <tls@ietf.org>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.1.170-22c6f66c430a71ce266a39bfe25bc2903e8d5c8f:6.0.391,18.0.790,17.0.607.475.0000000 definitions=2021-06-23_14:2021-06-23_01,2021-06-23_14,2020-04-07_01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxscore=0 adultscore=0 malwarescore=0 suspectscore=0 spamscore=0 clxscore=1015 mlxlogscore=700 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2106230134
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/lkjCDyUYVcm2JXuF7Mks2qDK8fM>
Subject: [TLS] Editorial: chronological order in ECH draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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, 23 Jun 2021 23:05:01 -0000

Hi all,

I'm bringing https://github.com/tlswg/draft-ietf-tls-esni/issues/412 to the list since it looks like we're (hopefully) getting close to the end game with ECH.

The ECH draft is currently organized such that it describes all client behavior and then all server behavior. Personally, I find this very confusing to follow, and I'm constantly having to flip back and forth between sections (which themselves constantly refer to each other). Does anyone object to my rearranging the content to be in more of the order in which things occur rather than being divided into client and server sections? Of course, depending on how I do it, it could end up being more confusing, but I just wanted to see if people were opposed to it in principle.

Carrick

v2.23.0 | Report a Bug | By Email