IETF Logo Mail Archive

Re: [TLS] Proposed change in TLS-Flags

Martin Thomson <mt@lowentropy.net> Wed, 01 July 2020 04:17 UTC

Return-Path: <mt@lowentropy.net>
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 61A893A0C0F for <tls@ietfa.amsl.com>; Tue, 30 Jun 2020 21:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=ZFq+ZgJc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QT4QGUJ/
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 flNj2CTSrDMu for <tls@ietfa.amsl.com>; Tue, 30 Jun 2020 21:17:43 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76F83A0C00 for <tls@ietf.org>; Tue, 30 Jun 2020 21:17:42 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2587A5C0164 for <tls@ietf.org>; Wed, 1 Jul 2020 00:17:42 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 01 Jul 2020 00:17:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=PGN3O D+38HmH/ecFkP/6qVcJ3exeXtrh5BnY/WijkmY=; b=ZFq+ZgJcF91TszvACC17i YJEiAVQT2SyZ0uS4uYcyq0OhqoCGjEpWt/IwlLm3lHjO7GyeGMPi+wT0ezSK8iBx j2C9Uz0H8LwiVL2GEWtbKtY/VZUMoXOTboJMPhAP/ZEFBxbKQJ3mAY2o7Dy3k8vj 4MbkaPD9XQlnOAZTfBSeUM9PoVDD1nRUNa2jwO5tHYZrq+J7dQKABO1UMKvRJ/n2 5mIqomycz/UPwKgeTPuVuCOPTBKQTeGuI0cin88Ou+tBHxP8hYAZ9ZyQ913RzbMO Kzu69V4h3EsJ3lHaSLwqd+8QcERwxRYibIcx0rOq26RjECCCPfg02Bl31wOlB7Vn g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=PGN3OD+38HmH/ecFkP/6qVcJ3exeXtrh5BnY/Wijk mY=; b=QT4QGUJ/5bmYwN9laP5j023lGMOxa3ZVOWRK4wdixJUH4NJMnExdX+0QX 7IbwB4+KJh4JrhNSUDUgvaCfdJFvPBprgTBr9ZWBumSgDeMzBlfS4oSRorQXo4b9 j3y15ttZQOrmsbviij8qw6a1mK0uRoYVqtHfSprJxMfFp9ic52LLjvLAyoU+7j6L hsBlVq62GKYwRTJ7mhZKQUZifUEo/LM4JapTVSmAZNPWBwaWMhFdeaEn3Y9hd6fO GahGetchsl3A5h+qS4awc9FZG03Oi/7VdHqDpiHaExzVtkYIgSEwZxLBaJmsSgHN wOeDy+I2QlqcdW9JGERLXvI2lReFQ==
X-ME-Sender: <xms:ZQ78Xtuj0E3rK-BNFx1RA83agDbvjG-wvihpI5cYTMrTVE0ffoA_DQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrtddugdekgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeehhedvhfehvefggeejtd egjeduveetleejvdekjeejhfekieekudelffdvudefffenucffohhmrghinhepghhithhh uhgsrdgtohhmpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:ZQ78Xmei5tSiLGPsHVbFU5T-g_YU_30b-w1fYCMlQAJgTBaiIjVtEw> <xmx:ZQ78XgwIcNzbnAVmSihOHX7ydNxESWNFJsy9RNLqTenuPxgyQWNv1g> <xmx:ZQ78XkOh4ZoOzTP3sfpsSLkcr3uiZ7WgGMRPPq9UhnKFIqSdAJzqew> <xmx:Zg78Xjc9hOsmUnXNSDMYVYQMPwLDIE-OPJhmj1lnLz26Csf2JR17dg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 993ADE00CE; Wed, 1 Jul 2020 00:17:41 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668
Mime-Version: 1.0
Message-Id: <b0e363f7-9326-4e03-9cc1-d640d9f637a9@www.fastmail.com>
In-Reply-To: <1496E3F4-FB87-46EE-9F76-86C058A55954@gmail.com>
References: <1CAC4193-E0CD-4C29-BC05-CED0617BEE19@gmail.com> <CAPDSy+7Mqn3fnYhUwGzo5tBNMTiBQeoKMcABQ_pzK-y7AhmipA@mail.gmail.com> <1496E3F4-FB87-46EE-9F76-86C058A55954@gmail.com>
Date: Wed, 01 Jul 2020 14:17:21 +1000
From: Martin Thomson <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sf6-x799iH4olXZE6E1plFTQdFg>
Subject: Re: [TLS] Proposed change in TLS-Flags
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, 01 Jul 2020 04:17:44 -0000

More to the point, this makes it more difficult to analyze relative to an empty "flag" extension of the likes we currently use.

I haven't implemented this, but I imagine one strategy would be to rewrite these flags and pretend that they were empty extensions.  That would allow implementations to reuse a lot of infrastructure, like the stuff we added for custom extensions.  That would be more difficult if the server can speak first.

On Wed, Jul 1, 2020, at 14:03, Yoav Nir wrote:
> Yeah, the thread that Nick mentioned.
> 
> Also, since there are no such extensions defined in the base TLS 1.3 
> spec, the server can’t assume that the client knows what either the 
> specific flag means, or the entire flags extension means. 
> 
> So suppose we invent some new client authentication scheme for TLS, it 
> does make sense for the server to signal that it supports this so that 
> the client can do. But I don’t think it’s too onerous to require that 
> the client indicate support first.
> 
> Yoav
> 
> > On 1 Jul 2020, at 2:30, David Schinazi <dschinazi.ietf@gmail.com> wrote:
> > 
> > Hi Yoav,
> > 
> > Could you elaborate on the rationale for this change please?
> > I was assuming that the ability for servers to send extensions not requested by clients was useful.
> > 
> > Thanks,
> > David
> > 
> > On Mon, Jun 29, 2020 at 2:34 PM Yoav Nir <ynir.ietf@gmail.com> wrote:
> >> Hi
> >> 
> >> I’ve just submitted the following PR:
> >> 
> >> https://github.com/tlswg/tls-flags/pull/4
> >> 
> >> Three changes:
> >>  * It is no longer allowed to send an empty flags extension. If you don’t support any flags, don’t send the extension.
> >>  * The server is no longer allowed to respond with flag types that the client didn’t indicate support for first.
> >>  * I’ve split the extension description section into a format section and a rules section
> >> 
> >> Please comment. Barring any objections, I’ll merge the PR just before the submission deadline.
> >> 
> >> Yoav
> >> 
> >> _______________________________________________
> >>  TLS mailing list
> >> TLS@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tls
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.28.0 | Report a Bug | By Email | System Status