[TLS] (crypto agility may benefit from private extensions) Re: Additional changes for draft-ietf-tls-iana-registry-updates

Rene Struik <rstruik.ext@gmail.com> Tue, 20 March 2018 14:51 UTC

Return-Path: <rstruik.ext@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8BD8B126D3F for <tls@ietfa.amsl.com>; Tue, 20 Mar 2018 07:51:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id NAQ9St5lAyfH for <tls@ietfa.amsl.com>; Tue, 20 Mar 2018 07:51:15 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 7C7991200B9 for <tls@ietf.org>; Tue, 20 Mar 2018 07:51:15 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id h76so4008492wme.4 for <tls@ietf.org>; Tue, 20 Mar 2018 07:51:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=KcmE+sDkCfzeJCLXsB8HIO2s2e/ib85Y8p/Zzx+/RII=; b=NfCXiNLDafd5TtUzaH5crb0hygxNqHSqPWvGZu8L6L2XIkxN4zq8F+YEp7mrwUc8jE 8ZkHAcL6hdZwjlP2R6cMWlBCCruzG3EPLxjvydAQ7SKC6bwG+KGS4S5hLD4Z6bwaBC3s aCm5BmEUWtxt++tL4nQalioazlNTo2evRw+BuiNgANem0/ccryMLnRvMOKhp8nxbd0hk YhCs5mToBSqS39uKn6caAYcQRBOGjEhNBJFgpOb4DZf60629ZifYrRBNUU/M6c+qIW1x jCYIkBEQONXPI1M3qNnrIxZHkmou/wPyf9I2fP2euEGD9zQt/QwPxctal9rIXXWdPU0+ maRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=KcmE+sDkCfzeJCLXsB8HIO2s2e/ib85Y8p/Zzx+/RII=; b=UiLfzwfQo7ioAErmUaXuN1zuBOSyHNStdgLhWRX1kEjh6vJ2Su9LZRhTlXxvZ0CvA4 DMN+EBvSzI9xmBPJr5bGJQM4HRJzvsDD50zeu7sEPSut0a2vYYO4dcqn6LfICQOFYUTV VSHc6AFmWxotEqg3YUqtrZve4Syo+22xn2x7oHU4KV3twVHCaO7t2ASRAfui1Q0vrF+k gwDUbsFwlVUxzFkHXW62pSHmyJSeVsMOkVod4soUbZiSS3YzoESbTYHM3E6pB0F6/Odv puXK0V/x897MtR9EXCavw7uWJo9xfkTES+7mxUqWf5z04d14TS4AW6wRMGfDy2n/Xu/B pLPA==
X-Gm-Message-State: AElRT7FFud0sO/t5TszESXZmmhYG5UwHeipekBP6s2pGtej/uKIsPUdJ OhShdJFyDgggiu5GXgTUWAvoaA==
X-Google-Smtp-Source: AG47ELu1EiYzUyPcSn6/mITT42JdSwRtWAp3oWrItb4w3PoSEF1pHRbMaPAmUJk3Q6Dof9tVycn0YQ==
X-Received: by with SMTP id b32mr17510463edc.116.1521557473721; Tue, 20 Mar 2018 07:51:13 -0700 (PDT)
Received: from [] (nat184.lu.usi.ch. []) by smtp.gmail.com with ESMTPSA id v9sm1979287edi.16.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 07:51:12 -0700 (PDT)
To: Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>" <tls@ietf.org>
References: <505FCF83-C92E-4A90-83BF-4B2C4796EBE6@sn3rd.com>
From: Rene Struik <rstruik.ext@gmail.com>
Message-ID: <dc28999a-b476-474f-a12b-d5170df76dec@gmail.com>
Date: Tue, 20 Mar 2018 10:51:11 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <505FCF83-C92E-4A90-83BF-4B2C4796EBE6@sn3rd.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/k0BGPpyN8zhNNSBhs_ZWipJEGjY>
Subject: [TLS] (crypto agility may benefit from private extensions) Re: Additional changes for draft-ietf-tls-iana-registry-updates
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 20 Mar 2018 14:51:17 -0000

Hi Sean:

Quick question: does "closing the registry" not contradict catering towards crypto agility? What happens if, say, one wishes to add another signature scheme, besides Ed25519, to the mix. If there is no private field, does this mean that, e.g., Schnorr+BSI Brainpool256r1 is now ruled out? 

My more serious concern is, however, that if the Private Use case is "verboten", there is no chance for people to signal private extensions (since IETF will just have killed this off).

I do not think it is prudent to have a slow process in place (IETF standardization) to effectuate crypto agility, if private use can already do this without waiting for 3-year public discussions and heated debate (if a weakness is discovered, dark forces will exploit this right away and won't wait for IETF to catch up to exploit an issue).

As case in point, suppose US Gov't wants to roll its own "Suite A" scheme, or if one wants to use TLS with something tailored towards the sensor world (which operates in quite a hostile environment for implementation security), how is one going to do this in context of TLS if the signaling required has just been removed?

NOTE: this is not an invite for endless discussions on the legitimacy of whoever may wish a private extensions (it is private after all), it does question though the wisdom of removing the option for using this. If Zulu hour arrives, one should have tools to act...

Best regards, Rene

On 3/16/2018 10:01 AM, Sean Turner wrote:
> During Adam Roach’s AD review of draft-ietf-tls-tls13, he noted something about the HashAlgorithm and that made me go look at what was said in draft-ietf-tls-iana-registry-updates.  Turns out that 4492bis assigned some values draft-ietf-tls-iana-registry-updates was marking as reserved.  I have fixed that up in:
> https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/65
> One further point brought out in discussions with Adam was that if we’re really closing the HashAlgorithm and SignatureAlgorithms registry we need to also mark 224-255 as deprecated.  Currently these are marked as Reserved for Private Use.  So the question is should we mark 224-255 as deprecated in these two registries?
> spt
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363