Re: [TLS] Comment on draft-thomson-tls-sic-00

"Martin Thomson" <mt@lowentropy.net> Thu, 11 April 2019 02:57 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 96CC1120471 for <tls@ietfa.amsl.com>; Wed, 10 Apr 2019 19:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=n0Qdg9rf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ghQU7h0Z
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 LzLtC6m6aHbB for <tls@ietfa.amsl.com>; Wed, 10 Apr 2019 19:57:51 -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 E94F512046F for <tls@ietf.org>; Wed, 10 Apr 2019 19:57:50 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D5E5920EF7 for <tls@ietf.org>; Wed, 10 Apr 2019 22:57:49 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 10 Apr 2019 22:57:49 -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; s=fm1; bh=camT3B+xczvUipuemyUBJmbQ9oe5PcG TtcAcJpUkeDA=; b=n0Qdg9rf2Aa0K9CvMaytXRzcsVXP6kXLeLwccU6iNdBLw2o 55gtyUzLztrTuWa+tglr3tTjtQDXBd0q548jbCWIhXmZavEbbpAsRwst0SBBN2lE kT0MqigL15d/WHoCX+4e9EMoasmZob/NPlw73iwbDXJK629Iz1pA2w9WD8wXJiu8 X5bKvt5G1LMylgDbHShUh6H+/2h2+RCmAl2ErT4JWxYuYsVQFYM4WluxtyM0/AgO 8uflBmY5b4AqzNTp4T3rp0wBYbtSCdj9Jl8xWgqRNno+uyytJkjqXwI3bbygX1Qt m5tDb3x1nuhjBPZOhDoCPMmfacWmDFS+Uoq8NXw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; bh=camT3B +xczvUipuemyUBJmbQ9oe5PcGTtcAcJpUkeDA=; b=ghQU7h0ZoXikeoEVdrYGLk NyNZi1ajrPdZR8t/G6aGlA5tb2m9xu5n3Z6yYuQS/EMdrcIYd1UHsPXuodexyyPm yW4ZmyzuBFYt1D0h42Lc6fFF7840TvQWUDU1iJKXn66nPrkfI2yv50uoog21p+XX dJwGVyDdUdcR+RQdFo7LR+MOUpUa1+n4dipTY4CH3IFWqEf5HUlEq8eF4yRbU25Z t+tN7SzUqUlFeN+VMl+cVvCH2WSF/tGUIqC6JGRB+8er3xIaTHj5USJegIR6U6si cGCQO3y+o3nX9mvakbuE/mxwKNXSXad+tAk0j0I/mmmF8gwXfGQBDoPCc8VTzV6A ==
X-ME-Sender: <xms:La2uXCoHV4uj7PYlcAVJw0J1M0TpH_9qKQ8PIgW58es6Jmn5MSHL1w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudekgdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:La2uXLwxqc_y9TZe4xPFLUsZAsfPcJlzLNzY2yyUzAeeGcgV8Ld29g> <xmx:La2uXNm7tuEL4JDOlCxDZGV-SCtzPW9VQ2cDrFHp6gMyArOhu4p7_g> <xmx:La2uXM3hMeQUn6mTyai_KJZmnH9ejA7BP2MypO1HIxGlNhy1jjwxoA> <xmx:La2uXITJCfJPOdtwVQgD6mj3HhCk-6vWFJlLfiuXOuu-j945nSq_BA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8130F7C130; Wed, 10 Apr 2019 22:57:49 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1
Mime-Version: 1.0
X-Me-Personality: 92534000
Message-Id: <523c1d42-c4bb-4206-b9be-bcec93973424@www.fastmail.com>
In-Reply-To: <3C099064-52D9-49C3-9180-A01FBDEE876A@ericsson.com>
References: <AC987170-3F9F-4682-B49B-872B9028692F@ericsson.com> <745ED9FE-9C31-4687-BD64-836155A28AEC@ericsson.com> <3C099064-52D9-49C3-9180-A01FBDEE876A@ericsson.com>
Date: Wed, 10 Apr 2019 22:57:52 -0400
From: Martin Thomson <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-T0W7OU-TU-gV8XNch4M025MZaU>
Subject: Re: [TLS] Comment on draft-thomson-tls-sic-00
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: Thu, 11 Apr 2019 02:57:53 -0000

On Sat, Mar 30, 2019, at 06:05, John Mattsson wrote:
> And one more....
> 
> "The 0xTBD flag can only be send in a ClientHello or CertificateRequest 
> message.  Endpoints that receive a value of 1 in any other handshake 
> message MUST generate a fatal illegal_parameter alert."
> 
> This goes against draft-nir-tls-tlsflags
> 
> "A server that supports this extension and also supports at least one 
> of the flag-type features that use this extension and that were 
> declared by the ClientHello extension SHALL send this extension with 
> the intersection of the flags it supports with the flags declared by 
> the client."
> 
> I assume the sic sic extension should be sent in EncryptedExtensions.

I think that this is a problem in draft-nir-tls-tlsflags.  Extensions in ClientHello are "answered" in two places: EncryptedExtensions and Certificate.  The requirement that the flag be echoed creates a problem in that context.

We could define separate "Handshake flags" and "Certificate flags", but that complicates things.

If you look at extension usage, you see that not all "flags" are echoed.  In this case, a requirement to echo would just increase the size of Certificate for no good reason - the extension can be omitted completely.

We should only require the presence of the flag where it carries semantics.  The requirement should be stated as

   Implementations MUST NOT set flags in extension responses if the remote
   endpoint did not send the corresponding flag in extension requests.  Upon
   receiving a flag that is incorrectly set, an endpoint MUST abort the handshake
   with an "unsupported_extension" [?] alert.

Mirroring the language from RFC 8446.