[TLS] Question about unrecognized extension types in the TLS 1.3 client hello message

"Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> Mon, 30 January 2017 21:41 UTC

Return-Path: <sfluhrer@cisco.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 A04AB1295F8 for <tls@ietfa.amsl.com>; Mon, 30 Jan 2017 13:41:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.72
X-Spam-Level:
X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 RBauzaZLfHhs for <tls@ietfa.amsl.com>; Mon, 30 Jan 2017 13:41:14 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81856129411 for <tls@ietf.org>; Mon, 30 Jan 2017 13:41:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8200; q=dns/txt; s=iport; t=1485812474; x=1487022074; h=from:to:subject:date:message-id:mime-version; bh=ghmfTEk0kUBo1SNDVlIob7aIjAgXuD+SgPWpLmS7UCc=; b=PfyUhhGidFbEyZLuQahjk/KM0CNCJfiHoko4M2N9/nxWxYg+cayRtSD1 H7bdHZaEZ018Ua0kWLr6g57FcVDH651WEkboWYTzJ4nA0eWtXZNDjdDeE 1e5iuvzHfiunR0WXA0FWZmGXWfSR2S/l/tpvpZ6zTpifyqgDQ98XDL/89 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ARAQCJso9Y/5hdJa1dGQEBAQEBAQEBAQEBBwEBAQEBgnBkYYEQjVeVH4xshSuCDIUSgzg/GAECAQEBAQEBAWIohR1eAYEAJgEEG4lZm0CSJosYAQEBAQYBAQEBASOGS4cEgh6FewWVQIYUAYFMkCWRAJJ+AR84gUsVhnSGaweBKYEMAQEB
X-IronPort-AV: E=Sophos;i="5.33,312,1477958400"; d="scan'208,217";a="378353050"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jan 2017 21:41:13 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v0ULfCxR009006 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <tls@ietf.org>; Mon, 30 Jan 2017 21:41:13 GMT
Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 30 Jan 2017 16:41:12 -0500
Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Mon, 30 Jan 2017 16:41:11 -0500
From: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: Question about unrecognized extension types in the TLS 1.3 client hello message
Thread-Index: AdJ7QZAvwr3Tl75aTkKB/t+x3+5diw==
Date: Mon, 30 Jan 2017 21:41:11 +0000
Message-ID: <747fda8b962b4edfab70afe2af58df36@XCH-RTP-006.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.98.2.62]
Content-Type: multipart/alternative; boundary="_000_747fda8b962b4edfab70afe2af58df36XCHRTP006ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/QGWdt5k04arwFzVqgDTwI0ZXRxs>
Subject: [TLS] Question about unrecognized extension types in the TLS 1.3 client hello message
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 30 Jan 2017 21:41:17 -0000

My question: in TLS 1.3, if the client inserts an extension of a type that the server does not recognize, how must the server behave?  Is it required that the server just ignore the extension, or can it take some other action (e.g. ignore the client hello)?

Background (why I'm asking): one of the things we've been doing is seeing how we might retrofit postquantum security into TLS 1.3; I know that the WG does not want to address this now, however I believe it will eventually; ideally, we could later create an RFC on how to do this within TLS 1.3 ( without having to come up with TLS 1.4).

The specific subtask we're looking at is how a postquantum key exchange (and a nonpostquantum one) can be used to generate keys.  Yes, I know that's been proposed before; I just want to make sure that it's actually kosher by the rules of TLS 1.3.  One goal that we have is to be able to have backwards compatibility with TLS 1.3 implementations that don't know about these post-quantum extensions.  One of the things we're looking at is having the client include an extension that would have some of the data; we would set things up so that if the server ignores the extension, the protocol acts "correctly" (that is, if the client and the server are both willing to use the same group, they'll interoperate, if not, then the connection will fail because both sides don't share a group in common).

So, a key requirement of this specific type extension is that the server ignores an extension it doesn't recognize.  We could do it without adding an extension; however that gets rather uglier.

I've been going through the TLS 1.3 draft (draft-ietf-tls-tls13-18), and there doesn't appear to be any MUST statements that says that the server ignores extensions it doesn't recognize.  There's a statement that a client MUST abort if it gets an extension it doesn't expect, but there's no similar language for the server.  Presumably, the server is supposed to be silent about zero length extensions from the client (as the draft states that the client sends a zero length extension for any type that it doesn't need to send, but is willing to receive in reply), however the extensions I'm asking about will not have zero length.

Is it the intension of the WG that the client is able to insert extensions into the client hello that the server might not expect?  If it is, could the next version of the draft insert a MUST statement to that effect?

Thank you.