Re: [TLS] integrity only ciphersuites

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 21 August 2018 11:41 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 36025130EE9 for <tls@ietfa.amsl.com>; Tue, 21 Aug 2018 04:41:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 pXQ0gNmdJJ1M for <tls@ietfa.amsl.com>; Tue, 21 Aug 2018 04:41:41 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6B1D130DE0 for <tls@ietf.org>; Tue, 21 Aug 2018 04:41:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 92EFABE56; Tue, 21 Aug 2018 12:41:37 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFbR9RCRXult; Tue, 21 Aug 2018 12:41:37 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 56FC5BE24; Tue, 21 Aug 2018 12:41:37 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1534851697; bh=bXtCZjwSCHSezA1E0o7k45rcQWWZcqJJTqJaQcSHiMY=; h=To:References:From:Subject:Date:In-Reply-To:From; b=iWeXu66V4VV8y+DxuXt1bwoW3HuvFecoOc+aH2l8jjPWohcilFKIGLjiL4tM81Asv KMLCudoRFAndRFmWddkgcPZadBFPu4BZhnFfk7uo8UcicBiYBvWtEMRQrCQP7vRHQz JTHDmLz8FpbfDfWEmk5gH0ClmrJnyBU19lo5iIzs=
To: "Nancy Cam-Winget (ncamwing)" <ncamwing=40cisco.com@dmarc.ietf.org>, "tls@ietf.org" <tls@ietf.org>
References: <E29465D4-E4C5-466F-9E3F-240E258DC7C2@cisco.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <64d23891-2f32-9bb8-1ec8-f4fad13cdfb9@cs.tcd.ie>
Date: Tue, 21 Aug 2018 12:41:36 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <E29465D4-E4C5-466F-9E3F-240E258DC7C2@cisco.com>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="UgG9Wcx1ZD0t45UrqeGMXJnxC81gJiTEw"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ozI_gJC6a0D-I39nqMst6cQm174>
Subject: Re: [TLS] integrity only ciphersuites
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.27
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, 21 Aug 2018 11:41:44 -0000


On 20/08/18 21:48, Nancy Cam-Winget (ncamwing) wrote:
> All, A couple IoT consortiums are trying to embrace the improvements
> made to TLS 1.3 and as they define their new security constructs
> would like to adopt the latest protocols, in this case TLS 1.3.   To
> that extent, they have a strong need for mutual authentication, but
> integrity only (no confidentiality) requirements.
> 
> In following the new IANA rules, we have posted the draft
> https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-00
> to document request for registrations of HMAC based cipher selections
> with TLS 1.3…..and are soliciting feedback from the WG on the draft
> and its path forward.

As ekr pointed out, with the new registration rules,
there's nothing to stop someone defining any old set
of crypto stuff and getting non-recommended codepoints.

That said, I don't consider that defining such
vulnerable-by-design ciphersuites is a good plan.

- It imposes costs on the non-niche users of TLS - once
these things are defined then developers and those who
deploy/configure applications using TLS need to check
that they're not using these undesirable ciphersuites,
so costs are being displaced from niche uses to the
vast majority of implementations and deployments, which
seems to me to be a bad idea. And we know that people
will sometimes get those checks wrong leading to unexpected
transmission of plaintext over the Internet.

- Similarly, just defining such ciphersuites seems likely
to lead to less well tested and infrequently used code
paths, which is undesirable. (Assuming someone pays some
developer to add these to some library, which generally
does seem to happen.)

- RFC7525 [1] is clear on this topic (after debate in the
UTA WG) - "Implementations MUST NOT negotiate the cipher
suites with NULL encryption" and I see nothing new to
convince me that that ought change for TLS1.3.

- Code footprint arguments aren't that convincing to
me - to get interop for the few devices where AES being
present or absent could make a real difference, you'd
need an awful lot more profiling of TLS or DTLS. I don't
see evidence of that so the interop/footprint arguments
seem pretty weak. I'd also bet that any useful "tiny
footprint" profile of that kind would end up targeting
loads of use-cases where confidentiality is absolutely
required.

- (In addition to the good points made by Geoffrey
Keating [2]) cleartext payloads would also assist in
device fingerprinting, making it easier to exploit
vulnerabilities at scale.

- IIUC there is also a desire to encrypt firmware
updates so that patches can be distributed more quickly
than attackers can reverse-engineer attacks. [4] I'm
not entirely sure if that's really likely to happen,
but if it were, then devices would need to be able to
use recommended ciphersuites in any case.

- TLS/AX.25 doesn't seem that good a plan in any
case - according to [3], which seems reasonable to
me, using clear-signed GPG is quicker and better
meets the oddball regulations. Attempting to deal
with those regulations by weakening TLS seems like
a very bad plan, as you'd fail in any case to achieve
interop with normal TLS applications like the web.
(And the advertising is as illegal as the crypto
apparently, though I do like that aspect:-)

- WRT unix sockets, I'm not clear that there's a
sufficiently important performance improvement in
real deployments to justify introducing weakened
ciphersuites - presumably mail servers are going to
use standard TLS libraries that (I hope!) won't be
offering NULL encryption, so I'd be surprised if
the right engineering decision was to prioritise
CPU to that extent, given the risks associated with
having weak ciphersuites present in widely used
implementations. IOW, it seems more sensible to me
for mail servers to just stick to using RECOMMENDED
ciphersuites. And given that you could use SASL
with Postfix/LMTP [5] I'm not sure why you'd want
a weirdo-version of TLS1.3 anyway but maybe there's
some reason I don't get.

- I think this WG has had to spend waaaay too much
time dealing with the "inspection of data" debate in
various forms, but we did get an answer (no consensus)
in the end for that. Niche use cases seem extremely
unlikely to me to justify revisiting that painful
topic.

So all in all, I just don't see a need for these
weak-by-design ciphersuites to even be defined. I'd
encourage folks who think they're needed to instead
think about how using RECOMMENDED ciphersuites might
make their implementations more widely applicable and
safer. Seems like a much more productive approach to
me anyway.

Regards,
S.

[1] https://tools.ietf.org/html/rfc7525
[2] https://mailarchive.ietf.org/arch/msg/tls/uI8xVgp7gTuJgwUyY-UgZfmUkRo
[3] https://tools.ietf.org/html/draft-ietf-suit-architecture-01#section-3.3
[4] https://www.tapr.org/pdf/DCC2010-AX.25-AuthenticationEffects-KE5LKY.pdf
[5] http://www.postfix.org/SASL_README.html#client_sasl