IETF Logo Mail Archive

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

Benjamin Kaduk <bkaduk@akamai.com> Mon, 09 May 2022 15:43 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 57605C15E6ED for <tls@ietfa.amsl.com>; Mon, 9 May 2022 08:43:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.669
X-Spam-Level:
X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.575, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9jDH8zRI2FR for <tls@ietfa.amsl.com>; Mon, 9 May 2022 08:43:30 -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 2FBF5C1595E5 for <tls@ietf.org>; Mon, 9 May 2022 08:43:29 -0700 (PDT)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 249DioCk019762; Mon, 9 May 2022 16:43:23 +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 : content-transfer-encoding : in-reply-to; s=jan2016.eng; bh=qaxMDWBYyUcUMcCYbT5SL9zTROZfdsAJtihcSdAP92s=; b=e5yUiufbt4TjB+j+dE4Bmoxg/q9BYM/vcSyhpcSvyFnSbN2B1T/C7UUtVQmIbVQWfUb1 l42Cq4PeneC5qSnTypiHB96Hr9LFsfksg+PLsGJ88roxGMyiZUqMaH+Jc125GQ0tp7yJ ab72SzR8ScrohdTPy8aOQUoFXDp4g+JNaZV2vRUV4FAoKIgjz96qlAsc5Hm1LBFbL9Kd MznX6tWKpjZYI89NAG46eSIXvY1m/faWlaDOP+gLyxG2pneS+/OBQlHzIsKCDqYv2JEH ckeVIU+iuciEWVh7K/j1Lx21ip8BmdnVp+uYtLMDYLEkkGLHgdlHF2xsgB4VEBOaVkbj nA==
Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0b-00190b01.pphosted.com (PPS) with ESMTPS id 3fxy9wq96d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 09 May 2022 16:43:23 +0100
Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 249FZ62G027756; Mon, 9 May 2022 11:43:22 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint6.akamai.com with ESMTP id 3fwm3yuxkt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 09 May 2022 11:43:22 -0400
Received: from usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) by usma1ex-dag4mb4.msg.corp.akamai.com (172.27.91.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.986.22; Mon, 9 May 2022 11:43:22 -0400
Received: from usma1ex-dag4mb2.msg.corp.akamai.com (172.27.91.21) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1497.32; Mon, 9 May 2022 11:43:21 -0400
Received: from akamai.com (172.19.16.38) by usma1ex-dag4mb2.msg.corp.akamai.com (172.27.91.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22 via Frontend Transport; Mon, 9 May 2022 11:43:21 -0400
Date: Mon, 9 May 2022 08:43:19 -0700
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Yoav Nir <ynir.ietf@gmail.com>
CC: Benjamin Kaduk <bkaduk=40akamai.com@dmarc.ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20220509154319.GC12383@akamai.com>
References: <CABcZeBPyqFSgdiUbgKk5QbHnDA_zT8RH_KROebTrUNOnfqZZGQ@mail.gmail.com> <20220413225130.GC3149@akamai.com> <00386759-28C6-4E54-BC9C-1C566D4A0B6D@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <00386759-28C6-4E54-BC9C-1C566D4A0B6D@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-05-09_04:2022-05-09, 2022-05-09 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 bulkscore=0 suspectscore=0 mlxlogscore=782 adultscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205090088
X-Proofpoint-ORIG-GUID: itj67zW_bmnQiX7iuzf4Gw0ughM3iZjt
X-Proofpoint-GUID: itj67zW_bmnQiX7iuzf4Gw0ughM3iZjt
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-05-09_05,2022-05-09_02,2022-02-23_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=767 priorityscore=1501 lowpriorityscore=0 bulkscore=0 clxscore=1011 malwarescore=0 impostorscore=0 adultscore=0 mlxscore=0 suspectscore=0 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205090088
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PwTX_lTJY_VQZ3asX9aGUf3wrjo>
Subject: Re: [TLS] Can flags be responded to with an extension?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.34
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: Mon, 09 May 2022 15:43:34 -0000

On Mon, May 09, 2022 at 06:10:43PM +0300, Yoav Nir wrote:
> 
> 
> > On 14 Apr 2022, at 1:51, Benjamin Kaduk <bkaduk=40akamai.com@dmarc.ietf.org> wrote:
> > 
> > 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.
> 
> I’m pretty sure we haven’t discussed this (or at least, I wasn’t in the room).  In my head it’s also disallowed.  In the text, it’s not explicitly disallowed, but the text does talk about response flags that are in flag extensions, not about responses that are in other extensions or other messages.  So implicitly disallowed?

I think the description in the abstract of the target class of extension as
those "that carry no interesting information except the 1-bit indication that a
certain optional feature is supported" also implicitly disallows response
bodies.

-Ben

v2.8.7 | Report a Bug | By Email