Re: [TLS] Can flags be responded to with an extension?

Benjamin Kaduk <bkaduk@akamai.com> Wed, 13 April 2022 22:51 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 BB59A3A18AF for <tls@ietfa.amsl.com>; Wed, 13 Apr 2022 15:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 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, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 FnKr20Gh3mF3 for <tls@ietfa.amsl.com>; Wed, 13 Apr 2022 15:51:39 -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 D349B3A18A7 for <tls@ietf.org>; Wed, 13 Apr 2022 15:51:37 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.17.1.5/8.17.1.5) with ESMTP id 23DL723g004900; Wed, 13 Apr 2022 23:51:35 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=9t8WzeD3PNrIzpOWM4powUCFTtfvIEXrKhMR6RWvXqE=; b=mw0oGzevCOj2ySpasB77BZ5jjWZhDXbGIFuxF7SC0+9BHWnFl7lDjrnrDYyvlvE/LmSc oFDAmRwyQ4nhv9DGaGJcwchOvI17FJ0Xk5eW+D7XWw76U7XQOfmYE5uJUDhSRCmnMszQ 7Ey8BWmWe7et+ut160q9Du08k0Jd3dbfxuNnlIJPwb3Oqa9hvCz4lZCWQQvTs7DafcRA pRZh3oB6ctugLzKIPh7CjOSXuK/Rfdivol1hlhME1SEvUvKhuO/bGXj+fdQT8fufb/uq SGO6sRMRILL8CRknU5ViRUPMAM/l/+UurEbf1Z42oILrQu7SllvduX9sFr1JTlB5Fah+ 6Q==
Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050096.ppops.net-00190b01. (PPS) with ESMTPS id 3fd3ajp47f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Apr 2022 23:51:35 +0100
Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 23DMo2mL019649; Wed, 13 Apr 2022 15:51:34 -0700
Received: from email.msg.corp.akamai.com ([172.27.91.22]) by prod-mail-ppoint5.akamai.com with ESMTP id 3fb84b7paj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Apr 2022 15:51:34 -0700
Received: from usma1ex-dag4mb6.msg.corp.akamai.com (172.27.91.25) by usma1ex-dag4mb3.msg.corp.akamai.com (172.27.91.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Wed, 13 Apr 2022 18:51:34 -0400
Received: from akamai.com (172.19.16.38) by usma1ex-dag4mb6.msg.corp.akamai.com (172.27.91.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22 via Frontend Transport; Wed, 13 Apr 2022 18:51:33 -0400
Date: Wed, 13 Apr 2022 15:51:31 -0700
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Eric Rescorla <ekr@rtfm.com>
CC: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20220413225130.GC3149@akamai.com>
References: <CABcZeBPyqFSgdiUbgKk5QbHnDA_zT8RH_KROebTrUNOnfqZZGQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABcZeBPyqFSgdiUbgKk5QbHnDA_zT8RH_KROebTrUNOnfqZZGQ@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486, 18.0.858 definitions=2022-04-13_04:2022-04-13, 2022-04-13 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 mlxlogscore=772 mlxscore=0 bulkscore=0 suspectscore=0 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2204130107
X-Proofpoint-ORIG-GUID: jSgDYXDQWtGEK2lV6hklQhG-wGb7NQGv
X-Proofpoint-GUID: jSgDYXDQWtGEK2lV6hklQhG-wGb7NQGv
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-04-13_04,2022-04-13_01,2022-02-23_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 clxscore=1011 malwarescore=0 mlxscore=0 priorityscore=1501 impostorscore=0 spamscore=0 suspectscore=0 mlxlogscore=775 bulkscore=0 lowpriorityscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2204130107
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/40t8pBBKBiJuSp_WPS_xkVrGphA>
Subject: Re: [TLS] Can flags be responded to with an extension?
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, 13 Apr 2022 22:51:44 -0000

On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote:
> Consider the case where the client wants to offer some capability that
> the server then responds to with real data, rather than just an
> acknowledgement.
> 
> For instance, supposing the SCT extension from RFC 6962 did not exist,
> the client would want to indicate support in CH and the server would
> send the SCT in CERT, but this extension would need to be non-empty
> and hence not a flag. draft-ietf-tls-tlsflags-09 seems a bit
> uncelar on this point (unless I'm missing it) but I think we
> should explicitly allow it.

In my head this was already disallowed.  I couldn't swear to whether
we actually talked about it previously or not, though.

-Ben