IETF Logo Mail Archive

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

Eric Rescorla <ekr@rtfm.com> Wed, 13 April 2022 17:57 UTC

Return-Path: <ekr@rtfm.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 D265E3A1D16 for <tls@ietfa.amsl.com>; Wed, 13 Apr 2022 10:57:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.gappssmtp.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 8hdegwcrLlwt for <tls@ietfa.amsl.com>; Wed, 13 Apr 2022 10:57:26 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 993A83A1D11 for <tls@ietf.org>; Wed, 13 Apr 2022 10:57:26 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id 9so2769690iou.5 for <tls@ietf.org>; Wed, 13 Apr 2022 10:57:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=ZzQCEqZbpPCenkoh1Rd175ziTl3AY2EVQJ4Qnbjzb5A=; b=0i6NJPTb/jz1Xl6k3kfVGBehDq50o/6DTgLyVhOu+Ci7rmRw186tXFeTeK8oIdRAOz GoRzruAzyfDfUek2W9bcrOfJYsCtOai+8lHPGSqDOhbX3b0jJsTg3q863rJwApVblUZy c/uBDcmKsSICPVuRtrzdrGUx0JUtxWs8Go+2soX5AiEVOiydN2kdWkwWeHniiDRpuKqw naQPPnDRU1WaOpAD2ZOm8fUryrLSY2GPrlolOoQPDFB1H4aZZiqCWZJPe4KPIvpTbEpi pEl6RM20W0Cm538UYL2ZPW5egxSuodMQuwqJo6UiO5juI2qIIo/uw4KbR0+tNFLvJ/rr 5lUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ZzQCEqZbpPCenkoh1Rd175ziTl3AY2EVQJ4Qnbjzb5A=; b=FNQnUwBoMhMQSoErVg9elnEa4pGX4OZQsiqSOuJJCRWYayKY3fUI1V2xELwqxE40Ks t39OfZmrrk/h2pqtvKx1VJX9g1RDUbVuo40ro56nk8pc46hHdCE24d6x7qCTNa8ToIDQ yCJJHR2LspRNt4lM81jwEKdkf+swh/tzGh62r0vIEa5/Qo1SPKeda0FNZzB9Iq/E1Zx6 Ijzr6ibAJbBy5yTxlw+iz+rBuu0ENrEVElAmh+b9oQrhl2nhQcKaYKMWpA3pgyDAMDn6 nUjOgfpF1O/lscP0EtMv6jHpyyJOB+pX9mN540EfIxAyDq6ldixK9egfX4nJ/LprJxYl FiBA==
X-Gm-Message-State: AOAM53072PxjeZCoOblq4lTFsZddosYvDQU9U9JCYntuufzaS86/yfTu nLFQuBKgu1k1CuIHsIXt4ujAJu0N4DNO/7hktulA+OqIRbPgKA==
X-Google-Smtp-Source: ABdhPJzudInUeYfa0bYrBG+49LH0rlFkQhpClN1Vab7hxUjbS24oUtiagphUFySzb2bnuCuJSSH+RAe3KZXzsHuHQcU=
X-Received: by 2002:a05:6638:1605:b0:326:2e61:8c18 with SMTP id x5-20020a056638160500b003262e618c18mr9026549jas.308.1649872645182; Wed, 13 Apr 2022 10:57:25 -0700 (PDT)
MIME-Version: 1.0
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 13 Apr 2022 10:56:49 -0700
Message-ID: <CABcZeBPyqFSgdiUbgKk5QbHnDA_zT8RH_KROebTrUNOnfqZZGQ@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f0e9b705dc8ce862"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MixxNxfOhR44gPjSFSLWoSK9xro>
Subject: [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 17:57:28 -0000

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.

Thoughts?
-Ekr

v2.23.0 | Report a Bug | By Email