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

Ted Lemon <mellon@fugue.com> Tue, 21 August 2018 17:29 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 A639D130FFB for <tls@ietfa.amsl.com>; Tue, 21 Aug 2018 10:29:50 -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=ham 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 wxi-Muf1uJMj for <tls@ietfa.amsl.com>; Tue, 21 Aug 2018 10:29:47 -0700 (PDT)
Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 05963130FE5 for <tls@ietf.org>; Tue, 21 Aug 2018 10:29:46 -0700 (PDT)
Received: by mail-it0-x231.google.com with SMTP id 139-v6so5141238itf.0 for <tls@ietf.org>; Tue, 21 Aug 2018 10:29:46 -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=MnwLh5t5q+N6U1UPNBe/SHvdy4OTFGYuqdoKz/XXjOk=; b=O3g/aIrAXELx0YdKSlwXz2brQvNCI3k+OBvCZB5W+ySmNMWIOJODYI+i/EWWCrfqbm UfzIwcVeFWdkZaAxi1SCpwn1anch9IkzU4QRWXrq0/r1YLvtDKrrwKftxy4oxYHz8b+O dd76G4GMwpo7Iq5BlBRqDcXzvNRLRXdQLFlXEYYmdecuh0WgAhGC4++U77JUnL6MFY7B ff26nWSHvEE7SCqDEaB0+5kyP/nBsb9p3V0OhmG+hEK9vyCWKy0GNW0Xuj/c3XgixuMZ Jrzlxqr+DJ3WhsImLwjc5VbihPTVReIqbm6anDNrIIzPzn0X8BJuLuJpyLzyutkXto4n Mi1A==
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=MnwLh5t5q+N6U1UPNBe/SHvdy4OTFGYuqdoKz/XXjOk=; b=Ld6PwI1XXO+x76RzfXlDOiZe3bntbkE5d7s/uIicTcdqpgKDuSTX8YmOjjP9KG1ubV LvhncjOhevI+8TOADr16gpYa8JhwVgFqapcvRaWvAH8b2H7glmTbZzyhsC6K1v/is7xY Xjh4cSsMSgzEFNDk96wiGuxdK60ByXyDL/pJjkChjiA51x3Tmvl/qM2ByLdz3agRoRa9 uFLmHLxCjE6KpopZYndoTEwWycXCM26V7RTlcNKznIJfoK1zcoK944k13nX78t0aWea9 5GyaUVmBDJyifn/pH0Ejznc0S7zj6yAe+zTl7hJaM+7mE6x2CMeDWtJ/NMYZl0YeMKVA J1Zg==
X-Gm-Message-State: APzg51ByZT4wfCJYw1oShMkoeLV4dBEpNi+7ZiIQbLLgpW02/JmYSRYn Zm2gtiDaEzUhaDy5jjZ2w3I0VtcXNIlYV5WkP5/oWg==
X-Google-Smtp-Source: ANB0Vdb90o1z2cQdQBwLGrnxMdzbg6eUhWQBPdpSlw4yFVqSanNkAIjzCV3XbL+KP6sUyZ1d/dBye8Ct5T2cmLgknks=
X-Received: by 2002:a24:5f92:: with SMTP id r140-v6mr245128itb.95.1534872586094; Tue, 21 Aug 2018 10:29:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Tue, 21 Aug 2018 10:29:05 -0700 (PDT)
In-Reply-To: <DM5PR2201MB1433B9D7F9AA3B7B688CD33C99310@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> <E6C9F0E527F94F4692731382340B337804AEFA24@DENBGAT9EH2MSX.ww902.siemens.net> <A51CF46A-8C5F-4013-A4CE-EB90A9EE94CA@akamai.com> <E6C9F0E527F94F4692731382340B337804AEFB10@DENBGAT9EH2MSX.ww902.siemens.net> <D5FF0E0E-F9C3-4843-AB77-19F45E3C00D5@akamai.com> <8A2746A8-6B41-45C3-9D77-6AF3536C6E2D@siemens.com> <DM5PR2201MB1433B9D7F9AA3B7B688CD33C99310@DM5PR2201MB1433.namprd22.prod.outlook.com>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 21 Aug 2018 13:29:05 -0400
Message-ID: <CAPt1N1mm9FzGknCUTOVZH_S=AsjutXS8qM7Ksa8xWwsSKKAgAg@mail.gmail.com>
To: Jack Visoky <jmvisoky@ra.rockwell.com>
Cc: "Fries, Steffen" <steffen.fries@siemens.com>, "Salz, Rich" <rsalz@akamai.com>, "ncamwing=40cisco.com@dmarc.ietf.org" <ncamwing=40cisco.com@dmarc.ietf.org>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000045256b0573f55fe8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/uAeZkW6KtWuPjMWE6EPtWsWTJ0U>
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 17:30:02 -0000

So rather than upgrading to TLS 1.3, why not just upgrade to IPsec?
 You're going to have to change what you do anyway—rather than arguing with
us why not bypass us entirely?

On Tue, Aug 21, 2018 at 1:06 PM, Jack Visoky <jmvisoky@ra.rockwell.com>
wrote:

> Just to pile on what Steffen is saying, the motivation for this is mainly
> around device communication that happens at high speeds (sub millisecond is
> not uncommon for an update rate).  The communications is generally not
> HTTP, but rather industrial protocols built on TCP and UDP.
>
>
>
> Thanks and Best Regards,
>
>
>
> --Jack
>
>
>
> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Fries, Steffen
> *Sent:* Tuesday, August 21, 2018 12:54 PM
> *To:* Salz, Rich <rsalz@akamai.com>
> *Cc:* ncamwing=40cisco.com@dmarc.ietf.org; tls@ietf.org
> *Subject:* EXTERNAL: Re: [TLS] integrity only ciphersuites
>
>
>
> [Use caution with links & attachments]
>
>
>
>
>
> On 21. Aug 2018, at 18:13, Salz, Rich <rsalz@akamai.com> wrote:
>
> ?  If there would be support for integrity ciphers in TLS 1.3 it would
> enable the straight forward switch from TLS 1.2 also in these environments
> by keeping existing monitoring options.
>
>
>
> Why do you want to move to TLS 1.3?  Why isn’t your existing solution good
> enough?
>
>
>
> ?  [stf] Currently it is sufficient to use TLS 1.2- For certain use cases
> the utilized components have a rather long lifetime. One assumption is that
> TLS 1.3 will exist longer that TLS 1.2 and that certain software tools
> (also browsers) may not support TLS 1.2 in the future  …
>
>
>
> Most browsers already do not support NULL encryption, and it is highly
> unlikely that any will add it for 1.3.  Have you any indication otherwise?
> If you’re not going to use the algorithms in general use on the public
> Internet, then you should expect that standard clients such as browsers,
> will not work.  PeterG can attest to this. :)
>
>
>
> True. I was more referring to an embedded device, which currently supports
> TLS 1.2 (for using integrity only) for machine to machine communication  If
> this device is accessed by a service technician, it will also use today
> cipher suites with encryption. If a browser provider decides to deprecate
> TLS 1.2 in the future, access by standard software would be hindered. This
> would end up in a device supporting TLS 1.3 for service technicians access
> and 1.2 for machine to machine communication to (still) have integrity
> only.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>