pect those with appropriate use cases to employ these
ciphers. So, procedurally, I think some review of (and authors updating) the
draft would be warranted?
Warm regards, Nancy
From: TLS on behalf of Eric Rescorla
Date: Tuesday, August 21, 2018 at 11:20
To: ""
Subject: Re: [TLS] EXT
Jack Visoky writes:
>What we did in ODVA was to add TLS (and DTLS in some cases) to protect this
>communication.
What about using LoRa security? That's actually a really nice design for a
lot of SCADA environments (particularly for something that came from a behind-
closed-doors background), an
No they should not be recommended (as a typical TLS use case includes
confidentiality requirement).
Yes this WG should review them and make a security statement, e.g., like "we
reviewed these suites and found that they do provide authentication and
integrity protection. No other protection such
On Tue, Aug 21, 2018 at 11:11 AM, Viktor Dukhovni
wrote:
>
>
> > On Aug 21, 2018, at 1:29 PM, Ted Lemon wrote:
> >
> > You're going to have to change what you do anyway—rather than arguing
> with us why not bypass us entirely?
>
> TLS is not just a WWW protocol. Other transport security use-c
> On Aug 21, 2018, at 1:29 PM, Ted Lemon wrote:
>
> You're going to have to change what you do anyway—rather than arguing with
> us why not bypass us entirely?
TLS is not just a WWW protocol. Other transport security use-cases
should not have to justify their existence.
It is, of course,
and Best Regards,
--Jack
From: Ted Lemon [mailto:mel...@fugue.com]
Sent: Tuesday, August 21, 2018 1:56 PM
To: Jack Visoky
Cc: Salz, Rich ; Fries, Steffen
; ncamwing=40cisco@dmarc.ietf.org; tls@ietf.org
Subject: Re: [TLS] EXTERNAL: Re: integrity only ciphersuites
What kind of bandwidth are
@ietf.org
Subject: Re: [TLS] EXTERNAL: Re: integrity only ciphersuites
Ø I’m not sure if I’m following the question, but what was meant was that
these ciphers are generally NOT used for browser access. Machine to machine
communication usually does not involve a browser. Apologies if I’ve
; --Jack
>
>
>
> *From:* Ted Lemon [mailto:mel...@fugue.com]
> *Sent:* Tuesday, August 21, 2018 1:39 PM
> *To:* Jack Visoky
> *Cc:* Salz, Rich ; Fries, Steffen <
> steffen.fr...@siemens.com>; ncamwing=40cisco@dmarc.ietf.org;
> tls@ietf.org
> *Subject:* Re: [TLS]
and Best Regards,
--Jack
From: Ted Lemon [mailto:mel...@fugue.com]
Sent: Tuesday, August 21, 2018 1:39 PM
To: Jack Visoky
Cc: Salz, Rich ; Fries, Steffen
; ncamwing=40cisco@dmarc.ietf.org; tls@ietf.org
Subject: Re: [TLS] EXTERNAL: Re: integrity only ciphersuites
If the device implements the
* I’m not sure if I’m following the question, but what was meant was that
these ciphers are generally NOT used for browser access. Machine to machine
communication usually does not involve a browser. Apologies if I’ve
misunderstood the question.
You understood me. So the devices (or rath
If the device implements the cipher so as to talk to the browser, it's
clearly capable of implementing the cipher...
On Tue, Aug 21, 2018 at 1:34 PM, Jack Visoky
wrote:
> Hi Rich,
>
>
>
> I’m not sure if I’m following the question, but what was meant was that
> these ciphers are generally NOT us
Hi Rich,
I’m not sure if I’m following the question, but what was meant was that these
ciphers are generally NOT used for browser access. Machine to machine
communication usually does not involve a browser. Apologies if I’ve
misunderstood the question.
Thanks and Best Regards,
--Jack
From:
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
wrote:
> Just to pile on what Steffen is saying, the motivation for this is
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 Bes
Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
Sent: Tuesday, August 21, 2018 12:38 PM
To: Ted Lemon ; Jack Visoky
Cc: ncamwing=40cisco@dmarc.ietf.org; tls@ietf.org
Subject: Re: [TLS] EXTERNAL: Re: integrity only ciphersuites
On 21/08/18 17:15, Ted Lemon wrote:
> I as
On 21/08/18 17:15, Ted Lemon wrote:
> 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?
If doing
needed.
>
>
>
> Thanks and Best Regards,
>
>
>
> --Jack
>
>
>
> *From:* Ted Lemon [mailto:mel...@fugue.com]
> *Sent:* Tuesday, August 21, 2018 10:58 AM
> *To:* Jack Visoky
> *Cc:* Andreas Walz ; tls@ietf.org; ncamwing=
> 40cisco@dmarc.ietf.or
, August 21, 2018 10:58 AM
To: Jack Visoky
Cc: Andreas Walz ; tls@ietf.org;
ncamwing=40cisco@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
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
com
(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.
Inventing your own null cipher security opens up the door for replay,
withhold and reorder styles of attacks.
On Mon, Aug 20, 2018 at 9:20 PM Peter Gutmann
wrote:
> Lyndon Nerenberg writes:
>
> >By law, we are forbidden from transmitting encrypted traffic, yet there
> are
> >use cases where in
Lyndon Nerenberg writes:
>By law, we are forbidden from transmitting encrypted traffic, yet there are
>use cases where integrity protection in the absence of data content
>protection would be of benefit.
I've worked a lot with a set of authentication-only channels that can't be
encrypted but nee
FWIW HAM might require public key signing rather than MACs, since MACs are
meaningless without a key.
On Mon, Aug 20, 2018 at 5:02 PM Lyndon Nerenberg wrote:
> There is one other -- admittedly esoteric! -- place where a NULL
> cipher would he useful: Amateur Radio applications.
>
> By law, we a
There is one other -- admittedly esoteric! -- place where a NULL
cipher would he useful: Amateur Radio applications.
By law, we are forbidden from transmitting encrypted traffic, yet
there are use cases where integrity protection in the absence of
data content protection would be of benefit.
A ve
On Mon, Aug 20, 2018 at 5:36 PM, Jack Visoky
wrote:
> 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
On Mon, Aug 20, 2018 at 2:36 PM, Jack Visoky
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
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 applic
27 matches
Mail list logo
