Re: [TLS] =?UTF-8?Q?Re:__FYI:_new_TLS_HandshakeType_allocation, _from_draft-ie?= tf-perc-srtp-ekt-diet

Benjamin Kaduk <> Mon, 02 September 2019 03:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50F951200FB for <>; Sun, 1 Sep 2019 20:22:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PrsQhhs8QvI7 for <>; Sun, 1 Sep 2019 20:22:51 -0700 (PDT)
Received: from ( [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0B5C12001B for <>; Sun, 1 Sep 2019 20:22:51 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x823H35i007686; Mon, 2 Sep 2019 04:22:49 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=R7oqJ5XwhMK+vCIuNNcGC+1EcLb8MB2/lDFAIlobjlA=; b=eLE9Ug7YSpEIIgJYRjeO9tKSH/zM1Gt42OA57kDlHo2lgSk0ELwpn/IDjLeLNe73rgxG Sl12XUldCRz/B8ZlMPYBRSZMBECAxJSD0aXDof0YA4dCpzSTJtYMR7Lji5rtCzgl8erV lBvK8lGAulXhlZKOp17ddWh8EkJn5EuhcYY83O4bnUp4LYDoAVcKSU/AUGaGxNcK09MY CZALL6sry5raIt+JoMCoJOvl4WRBDkj8eL0QH1kaKZq8fD35t/5aGJFLbEJyAY0+R9yU 8rZifvqu2oasB7J70pP2vViMkLgn9npz6iinG19Kr+ndlDIwLAjXuyXjmlv5/hCKgLqp wA==
Received: from prod-mail-ppoint7 ( [] (may be forged)) by with ESMTP id 2uqha7r3pd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 02 Sep 2019 04:22:49 +0100
Received: from pps.filterd ( []) by ( with SMTP id x823H1tg025371; Sun, 1 Sep 2019 23:22:48 -0400
Received: from ([]) by with ESMTP id 2uqm81bf3g-1; Sun, 01 Sep 2019 23:22:48 -0400
Received: from ( []) by (Postfix) with ESMTP id 5E8D581394; Mon, 2 Sep 2019 03:22:48 +0000 (GMT)
Received: from bkaduk by with local (Exim 4.86_2) (envelope-from <>) id 1i4cvW-0001L1-TK; Sun, 01 Sep 2019 22:22:46 -0500
Date: Sun, 01 Sep 2019 22:22:46 -0500
From: Benjamin Kaduk <>
To: Martin Thomson <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-02_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1909020037
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-02_01:2019-08-29,2019-09-02 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 mlxlogscore=999 priorityscore=1501 spamscore=0 bulkscore=0 adultscore=0 clxscore=1015 phishscore=0 suspectscore=0 lowpriorityscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1909020037
Archived-At: <>
Subject: Re: [TLS] Re: FYI: new TLS HandshakeType allocation, from draft-ie tf-perc-srtp-ekt-diet
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Sep 2019 03:22:53 -0000

On Mon, Sep 02, 2019 at 10:28:36AM +1000, Martin Thomson wrote:
> Which value do they want?  As we have previously established in relation to the discussion on connection IDs and handshake types, there are values that would be sent in the clear in (D)TLS 1.3, which have very tight constraints, and those that would be sent under encryption, which might not need so close scrutiny.

This one would be sent encrypted -- the contents need to be encrypted,
which impacted which mechanisms were viable for them.

> I get the impression that there are constraints here.  This will likely be multiplexed in an RFC 7983 sense in DTLS 1.2, so the range of values here is narrow.  But not as narrow as to require access to the prime space between 20 and 31 that we are using for handshake types that need to be sent in the clear. I think that we should encourage the use of a value >= 32 in this case.

I don't think the specific value to allocate has come up yet; I'll try
to remember to keep an eye out once IANA gets to that point.