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

Eric Rescorla <ekr@rtfm.com> Mon, 20 August 2018 22:30 UTC

Return-Path: <ekr@rtfm.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 43E8C130EB1 for <tls@ietfa.amsl.com>; Mon, 20 Aug 2018 15:30:07 -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, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 rwSmL_vIRzVV for <tls@ietfa.amsl.com>; Mon, 20 Aug 2018 15:30:04 -0700 (PDT)
Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 64BAC130DF0 for <tls@ietf.org>; Mon, 20 Aug 2018 15:30:03 -0700 (PDT)
Received: by mail-lj1-x244.google.com with SMTP id v9-v6so12809248ljk.4 for <tls@ietf.org>; Mon, 20 Aug 2018 15:30:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cKISf3//fg5Hcymqa3JgqcEpuPWxAy9Zm6uNaTHISbg=; b=EnR7yCkeCclj9oylWURHaGgkrQLbYh0Ut8EAhFZqbZp5IOBibE4I2+o7DBa791qlBG avcjCHRJ7s9Dlxn4+f4LCCbBSETDN5P/Uz174u12PIY/fodcincpfoOeAPBDGxGHUyzy pCYVFhvAn4xz8FD3Hc7cwB+BG4YMK7jA2BYxsUg3fHY6B0yB6WNHA4JoErZpk+9OlIzR w74oNO9BS2pKRJMGur9aPgyCNhrxhE/k0c+H+YbUwW6f4s+q2lo5d/45GrlNZxR335uI HpTbsOSg+aa9uy3u44mPw/hyRfHfO1NAkIT3NhloQvvLp7a8Aot+D2cCpNpVY5rJ27T9 F3MA==
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=cKISf3//fg5Hcymqa3JgqcEpuPWxAy9Zm6uNaTHISbg=; b=Iq7s21N9y1oBOd43aqBHMxppvisKUapexLCSqxr6QsQDxUQw1UMpDM6jmC5rdAgUIo 0TN6UWj1Jpadesqm/nIf1AKQHHOEbvIDIkKH8i3JTMWFRd7uSN661X/M++rvkkmirtdF twkHVqWPIPZPHymLlClDIVMiOTNgaijZXX2m4/x6zmculMdQsnxCdxapBypBxYBfXzC9 cCnCe3+UBDibQ2k0CI48U3/42X0PACQN/CFbu4ogqT3sSSeJ8yOgFp4hWQ6bKHvrK/1W IJlQm83nftq12fliPEDB1zwPB9P7H+YRaRfGk+TSOpjxpxVSzu0L5wqzMWiU0lpRVk33 l44g==
X-Gm-Message-State: APzg51AxMn/ZdKA04SbcZ/A5MhUx0S1j+xqRBorzb+9QXxOTk98hDYXk u1M64EkygEWJ+LmTvMPry8vQ3sdibTzwr6eXVv/0Bw==
X-Google-Smtp-Source: ANB0VdZv1EcoBGyClnQ0pgxnduqtPGmAw6xOxH+TZ9pweh133g9vBBd3WEPfEbmpayG2ikOArDIOVn1v6iV2nLdE89s=
X-Received: by 2002:a2e:1bd7:: with SMTP id c84-v6mr606062ljf.0.1534804201536; Mon, 20 Aug 2018 15:30:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 15:29:20 -0700 (PDT)
In-Reply-To: <DM5PR2201MB1433AABB629D610944E470D899320@DM5PR2201MB1433.namprd22.prod.outlook.com>
References: <E29465D4-E4C5-466F-9E3F-240E258DC7C2@cisco.com> <CABcZeBNpgnfBerkutLB0jKA4vF_FrpXNHnEeKQhAOFm-y=xJsA@mail.gmail.com> <DM5PR2201MB1433AABB629D610944E470D899320@DM5PR2201MB1433.namprd22.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 20 Aug 2018 15:29:20 -0700
Message-ID: <CABcZeBNsDdb_uKxvbkz+EQEf6xe-UvOpAaU8jEgBPh=irQE1ig@mail.gmail.com>
To: Jack Visoky <jmvisoky@ra.rockwell.com>
Cc: "Nancy Cam-Winget (ncamwing)" <ncamwing=40cisco.com@dmarc.ietf.org>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003b937f0573e57327"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/gJexrwZX9zD5JpBiAduZPxO_Exc>
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: Mon, 20 Aug 2018 22:30:12 -0000

On Mon, Aug 20, 2018 at 2:36 PM, Jack Visoky <jmvisoky@ra.rockwell.com>
wrote:

> Hi Eric,
>
> Thanks for your feedback.  Just a few points to add:
>
> 1. There really are some applications where confidentiality isn’t
> important, for example some motion control that might involve very simple
> move instructions (e.g. go to X, go to Y, go to Z, repeat).  Certainly
> there are also applications that would benefit from confidentiality, but
> there’s a non-trivial amount that really gain little to nothing.
>

Why do you think this isn't sensitive information? I can imagine scenarios
where it's not, but it also might be, as, for instance, it leaks the level
of activity of the device.

2. In some cases the code size is quite important.  It’s not uncommon for
> hardware to be in the field in Industrial Automation for 15 or more years,
> so in some cases the hardware is already stretched pretty thin and might
> not be able to handle the demands of encryption.  At the same time it is
> hugely beneficial to take advantage of the security of TLS for many of
> these installations.
>

This seems not very specific. Can you provide some actual numbers for the
difference in code size to have encryption as a fraction of the total code
size?



> 3. Another use case for these NULL encryption suites is around inspection
> of data.  I think this has been discussed in this forum already, but these
> cipher suites could support that as well.
>

Supporting this use case is not really a priority for this WG. In fact,
it's part of why we removed these ciphers in TLS 1.3.

-Ekr


> Thanks and Best Regards,
>
> Jack Visoky
> Security Architect and Sr. Project Engineer
> Common Architecture and Technology Group
> Rockwell Automation | 1 Allen-Bradley Drive | Mayfield Heights, OH 44124
>
>
>
> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric Rescorla
> Sent: Monday, August 20, 2018 4:58 PM
> To: Nancy Cam-Winget (ncamwing) <ncamwing=40cisco.com@dmarc.ietf.org>
> Cc: tls@ietf.org
> Subject: EXTERNAL: Re: [TLS] integrity only ciphersuites
>
> [Use caution with links & attachments]
>
>
>
> On Mon, Aug 20, 2018 at 1:48 PM, Nancy Cam-Winget (ncamwing) <ncamwing=
> 40cisco.com@dmarc.ietf.org> 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.
>
> Nancy,
>
> As you say, you don't need WG approval for code point registration as long
> as you don't want Recommended status.
>
> With that said, I don't think this document makes a very strong case for
> these cipher suites. Essentially you say:
>
> 1. We don't need confidentiality
> 2. Code footprint is important
>
> Generally, I'm not very enthusiastic about argument (1). It's often the
> case that applications superficially need integrity but actually rely on
> confidentiality in some way (the obvious case is that HTTP Cookies are an
> authentication mechanism, but because they are a bearer token, you actually
> need confidentiatilty). It's much easier to just always supply
> confidentiality than to try to reason about when it is or is not needed.
>
> The second argument is that you are trying to keep code size down. It's
> true that not having AES is cheaper than having AES, but it's possible to
> have very lightweight AES stacks (see for instance:
> https://github.com/01org/tinycrypt).
>
> So, overall, this doesn't seem very compelling..
>
> -Ekr
>
>
>
>
> Warm regards, Nancy (and Jack)
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>