Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

Ted Lemon <mellon@fugue.com> Tue, 21 August 2018 16:16 UTC

Return-Path: <mellon@fugue.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 EC008130E45 for <tls@ietfa.amsl.com>; Tue, 21 Aug 2018 09:16:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 jaQs0K8o8yss for <tls@ietfa.amsl.com>; Tue, 21 Aug 2018 09:16:17 -0700 (PDT)
Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 6E5FB130DC3 for <tls@ietf.org>; Tue, 21 Aug 2018 09:16:17 -0700 (PDT)
Received: by mail-io0-x242.google.com with SMTP id y12-v6so6113029ioj.13 for <tls@ietf.org>; Tue, 21 Aug 2018 09:16:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1DFC3feNXQkNDKHm4GrY/FtsQs8nUd5fHonnqfCKrKM=; b=zzChveEG948ivDVP1IB6fAqM3yE5Tvg2lfo3SRjL2LM7TT/DBjOcgBnC0YID+oA8I7 NrR9rWsZ+Mijo09JCEd5l1yh18NHrGcN1Ok5z6iFTYykHbyV9q1E3jKY9B9crZPI2cIC I8J6mdS53m86YeA4W6erWfkjVk0bHGQAqAvxb872+qnSuGdm31dBUKACg94AoOPeZL9G s2c3Gt7jeymzE3dWxV51UqAI5u0YIwwZmSh5GtKddHF+So/mr7nN5OtGFNmy0M3TOt9b mf9oBZZlqTvjroaNsOUpQoo3ZOnNnNVMAd3GH0RrAyegs7a9UkBoq78av91IiS4B9fky W7EQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1DFC3feNXQkNDKHm4GrY/FtsQs8nUd5fHonnqfCKrKM=; b=VLUxUCWN07UUX3C+zEZM8lg3+zzshavs90sjHhT3YYhal8s3P7F6kV1MIyMLAPf4BF /h6xy3ft+tDNtiY2EbNsR1oO8ttXxmRp8XNPayG1o4JtO+xaivuv9yC4dH34NGySWoHI VpjjUTRc0jTp1rXbrA84k8iJdLE9dlpxca1Cu92Uko2whSm0navepFdXC3SYGI5JLnft Fhnsh6xcPyhnkQicSf+dolEVAAeo95CO5JI9qnGQa2uQTNF7KjbfIJ05Ln5pstiVhN0K DkkPRPhC1QnCeHZZ5ZMkjpqlcCeQY3F2nVKqrZ/D/XmgCvTHuiO3XV1a93R/h1vxfqD3 U1fw==
X-Gm-Message-State: AOUpUlFSZlsawvvkFFinIuNOuq37gF5Sc+CNz1SAtJqAYaDhgk5mN+bZ fJ60nIo5l/ZDHUaoDkoLY9iXquqVscP5Kzw0ePQ56A==
X-Google-Smtp-Source: AA+uWPy3cWwN1FbOWO+uH+L3q+8dbdFTY5QB9+etBfmKdKG+jOLcIPkm6E/qCO/BjW/LZld0gQ6b/u856ms+Vrh+c8M=
X-Received: by 2002:a6b:4c5:: with SMTP id 188-v6mr44740123ioe.32.1534868176626; Tue, 21 Aug 2018 09:16:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Tue, 21 Aug 2018 09:15:36 -0700 (PDT)
In-Reply-To: <DM5PR2201MB14332BE29A418B74DF8E2AD299310@DM5PR2201MB1433.namprd22.prod.outlook.com>
References: <E29465D4-E4C5-466F-9E3F-240E258DC7C2@cisco.com> <64d23891-2f32-9bb8-1ec8-f4fad13cdfb9@cs.tcd.ie> <982363FD-A839-4175-BA53-7CA242F9ADA6@ll.mit.edu> <2D7F2926-6376-4B2C-BDE9-7A6F1C0FA748@gmail.com> <5B7C1571020000AC0015C330@gwia2.rz.hs-offenburg.de> <DM5PR2201MB14335F5B8FBF5DC0B64B2AEF99310@DM5PR2201MB1433.namprd22.prod.outlook.com> <CAPt1N1=BLy5Y1Ecf6zPbC0UkXKCeKAavtKs=K5u5pL_a6CPtBw@mail.gmail.com> <DM5PR2201MB14332BE29A418B74DF8E2AD299310@DM5PR2201MB1433.namprd22.prod.outlook.com>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 21 Aug 2018 12:15:36 -0400
Message-ID: <CAPt1N1kBCRw5hES1DA7DDac5GA=LdYeyvyBcaiHOzvsK6ATMyQ@mail.gmail.com>
To: Jack Visoky <jmvisoky@ra.rockwell.com>
Cc: Andreas Walz <andreas.walz@hs-offenburg.de>, "tls@ietf.org" <tls@ietf.org>, "ncamwing=40cisco.com@dmarc.ietf.org" <ncamwing=40cisco.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000071ff320573f45824"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Zpt9rjmbK5hF9RMrpt3iNmTm9jw>
Subject: Re: [TLS] EXTERNAL: Re: 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 16:16:22 -0000

I asked you if you have any specific devices for which this is an issue.
 Do you?   How did you determine that it was an issue?   Do you have A/B
testing results on power consumption and/or performance of a null cipher
suite versus encryption?

On Tue, Aug 21, 2018 at 11:20 AM, Jack Visoky <jmvisoky@ra.rockwell.com>
wrote:

> Hi Ted,
>
>
>
> My apologies for being opaque.  There are many different
> device/applications/installations so I am sorry if I am mixing ideas
> here.  Generally the NULL ciphers have the benefit around allowing higher
> performance for devices that are lower horsepower.  Code space can
> certainly be a concern, but I think for industrial applications it’s more
> around throughput of high speed I/O, combined with the use cases that
> derive little benefit from the confidentiality of this data.  “Horsepower”
> is of course a vague term in of itself, so here I’m talking about things
> that would impact packet processing; this includes processor speed,
> available high speed RAM, presence of/lack of crypto acceleration (not in
> many Industrial Ethernet devices but growing).  I wouldn’t put the
> executable code size as high on the list of concerns as these items,
> although there are certainly devices that are limited in this.  This
> horsepower limitation is directly related to the fact that these devices
> are expected to function for many years.
>
>
>
> I’m happy to clarify any of these points further if needed.
>
>
>
> Thanks and Best Regards,
>
>
>
> --Jack
>
>
>
> *From:* Ted Lemon [mailto:mellon@fugue.com]
> *Sent:* Tuesday, August 21, 2018 10:58 AM
> *To:* Jack Visoky <jmvisoky@ra.rockwell.com>
> *Cc:* Andreas Walz <andreas.walz@hs-offenburg.de>; tls@ietf.org; ncamwing=
> 40cisco.com@dmarc.ietf.org
> *Subject:* Re: [TLS] EXTERNAL: Re: integrity only ciphersuites
>
>
>
> Thanks, Jack, but could you respond to the specific questions that we
> asked you?   Earlier you were saying that your motivation for using NULL
> ciphers was that you had specific hardware that couldn't implement
> encryption due to lack of horsepower or memory.   Now you seem to be saying
> something completely different.   It's going to be difficult for us to
> understand your requirements if you talk about different things in each
> message.
>
>
>
> On Tue, Aug 21, 2018 at 10:27 AM, Jack Visoky <jmvisoky@ra.rockwell.com>
> wrote:
>
> (I’m responding  a few different points made here)
>
>
>
> In general, although this seems like a niche application, there are
> actually millions of Industrial Ethernet nodes, with the numbers trending
> upward.  As mentioned, many of these are relying on older protocols
> designed without security in mind.  Our industry has had a debate around
> using TLS vs. creating something specific.  Many of us prefer to rely on
> the security benefits of TLS.  To another point, although I work for
> Rockwell Automation, here I am working in my capacity within ODVA, a
> standards group for Industrial Communications that has several large
> vendors as members.  We have adopted TLS to protect our industrial Ethernet
> traffic, and one of the selling points of TLS 1.2 was the ability to use
> NULL encryption.
>
>
>
> NULL encryption is not really as much about code size but capability of
> the devices.  The TLS handshake of course contains some “heavyweight”
> operations, although handshakes are pretty infrequent as these connections
> are often quite long-lived.  Once the handshake is over, the I/O data that
> is transferred is often quite sensitive to latency, and although the
> encryption overhead might not seem like much when the HMAC is considered,
> it is still a case where in many applications every bit counts.  Regarding
> older hardware that exists for many years, some hardware does have
> cryptographic acceleration although may not have AES-GCM, rather SHA-256
> HMAC.  Alternatively, the hardware might not have any crypto acceleration
> as it was designed without TLS in mind.  At the same time we’d like to
> secure this traffic via a firmware upgrade.  Despite this, if using
> encryption drops performance enough users will simply not use it, which is
> a net worse outcome.  Users will likely not upgrade hardware for many years
> due to a variety of industry factors.
>
>
>
> Kathleen’s comment about defining NULL encryption but being clear about
> the risks resonates with me.  I’m certainly not suggesting that NULL
> encryption is needed in all cases, but there are times (as discussed here
> and in the RFC draft) where it could be quite beneficial.
>
>
>
> Thanks and Best Regards,
>
>
>
> --Jack
>
>
>
> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Andreas Walz
> *Sent:* Tuesday, August 21, 2018 9:37 AM
> *To:* tls@ietf.org
> *Cc:* ncamwing=40cisco.com@dmarc.ietf.org
> *Subject:* EXTERNAL: Re: [TLS] integrity only ciphersuites
>
>
>
> [Use caution with links & attachments]
>
>
>
> +1
>
> I fully understand the pursuit of minimizing complexity in TLS. However,
> banning from TLS all provisions to serve non-internet cases seems
> suboptimal to me.
>
> I think there is a whole universe of systems and applications that are
> just at the very beginning of being armed with security features: think of
> communication systems driving, e.g., industrial automation and critical
> infrastructures. These are quite different from the internet and the web
> (different threats, security requirements, architectures, networks,
> resources, etc.). Still, IMHO it's not a niche at all; it's just not as
> visible to most of us.
>
> I strongly believe it is *not* a good idea to hold back all the valuable
> experience condensed in TLS and entail the design of customized security
> protocols for such systems. TLS is state-of-the-art and its benefits should
> be accessible to as many systems as possible.
>
>
>
> Cheers,
> Andi Walz
>
>
>
>
> >>> Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> 08/21/18 3:20 PM
> >>>
>
>
> Sent from my mobile device
>
> > On Aug 21, 2018, at 8:10 AM, Blumenthal, Uri - 0553 - MITLL <
> uri@ll.mit.edu> wrote:
> >
> > "Vulnerable-by-design ciphersuites"? Vulnerable to what?
> >
> > Suck sites are designed to provide end-point authentication and traffic
> integrity. Care to explain/show how these properties would not hold?
> >
> > Besides, it's been explained several times that some use cases do not
> require confidentiality, and in some use cases confidentiality is forbidden.
>
> I agree with Uri here, flexibility to cover these use cases to accommodate
> the actual security requirements may result in them using something instead
> of nothing. It could be defined and not listed as Recommended as well. This
> comes down to risk management and options, where the risk can be clearly
> explained and the lack of recommendation can also be explained.
>
> Best regards,
> Kathleen
>
> >
> > Regards,
> > Uri
> >
> > Sent from my iPhone
> >
> >> On Aug 21, 2018, at 07:42, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
> >>
> >>
> >>
> >>> 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
> >>
> >>
> >> <0x5AB2FAF17B172BEA.asc>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> 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
>
>
>