Hi Geoff and Richard,
Thanks for raising these points….please see below for my comments:
From: Richard Barnes
Date: Tuesday, August 21, 2018 at 07:06
To: "geo...@geoffk.org"
Cc: "ncamw...@cisco.com" , ""
Subject: Re: [TLS] integrity only ciphersuites
On Mon, Au
Salz, Rich writes:
>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
On Wed, Aug 22, 2018 at 12:07 AM Richard Barnes wrote:
> I'm agnostic w.r.t. confidentiality of application data -- we've historically
> been bad at making decision about what does / does not need to be
> confidential, but hey, it's your data.
Isn't this assumption - "this data is mine" - part
On 8/21/18 at 7:24 AM, stephen.farr...@cs.tcd.ie (Stephen
Farrell) wrote:
I agree. Quoting the meat of the abstract of RFC8446:
TLS allows client/server applications to communicate
over the Internet in a way that is designed to prevent eavesdropping,
tampering, and message forgery.
I spent
Now I think I am as confused as Stephen and others.
One justification was “small footprint.” But now you’re saying that for
debugging encryption (standard?) ciphers are used for browser access?
___
TLS mailing list
TLS@ietf.org
On 21. Aug 2018, at 18:13, Salz, Rich
mailto:rs...@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
Ø 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
This is a situation where there is a clear alternative: use IPsec. IPsec
is ideal for the problem space you are in. TLS is actually really not
ideal. You are trying to cram a round peg into a square hole.
On Tue, Aug 21, 2018 at 12:00 PM, Fries, Steffen
wrote:
>
>
>
>
> Ø If there would
Ø 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
* 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?
: ncamwing=40cisco@dmarc.ietf.org
Subject: Re: [TLS] integrity only ciphersuites
+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
On 21/08/18 14:36, Andreas Walz wrote:
>
> 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
On Aug 21, 2018, at 10:16, Stephen Farrell wrote:
—
Regards,
Uri Blumenthal Voice: (781) 981-1638
Secure Resilient Systems and Technologies Fax: (781) 981-7537
MIT Lincoln Laboratory
244 Wood Street, Lexington, MA 02421-9185
Web:
Hiya,
On 21/08/18 13:10, Blumenthal, Uri - 0553 - MITLL wrote:
> "Vulnerable-by-design ciphersuites"? Vulnerable to what?
Accidental use, at least. If libraries implemented this
it could create a need for "!NULL" additions to random
configurations for example.
(I do accept that
On Mon, Aug 20, 2018 at 7:46 PM Geoffrey Keating wrote:
> "Nancy Cam-Winget \(ncamwing\)"
> writes:
>
> > 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
+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:
One area where there is a need for an integrity and
authentication only suite is in amateur radio systems. In
amateur radio, any encoding scheme which hides the meaning of a
message is against the FCC regulations. However, remote control
by radio could benefit from both integrity and
Sent from my mobile device
> On Aug 21, 2018, at 8:10 AM, Blumenthal, Uri - 0553 - MITLL
> 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
> On Aug 21, 2018, at 12:32 AM, Viktor Dukhovni wrote:
>
> There is also a use-case for communication between processes on the same
> machine, e.g. over unix-domain sockets and the like. Encryption in this
> context is pointless. TLS can be used with client certificates as a means
> of
"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,
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
> On Aug 20, 2018, at 4:57 PM, Eric Rescorla wrote:
>
> 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
There is also a use-case for communication between
"Nancy Cam-Winget \(ncamwing\)" writes:
> 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
018 at 13:58
> *To: *"ncamw...@cisco.com"
> *Cc: *"tls@ietf.org"
>
>
> *Subject: *Re: [TLS] integrity only ciphersuites
>
>
>
>
>
>
>
> On Mon, Aug 20, 2018 at 1:48 PM, Nancy Cam-Winget (ncamwing) <
> ncamwing=40cisco@dmarc.ietf.o
Hi Eric,
Thanks for the prompt feedback! Please see further comments/questions below:
From: Eric Rescorla
Date: Monday, August 20, 2018 at 13:58
To: "ncamw...@cisco.com"
Cc: "tls@ietf.org"
Subject: Re: [TLS] integrity only ciphersuites
On Mon, Aug 20, 2018 at 1:48
To: Nancy Cam-Winget (ncamwing)
Cc: tls@ietf.org
Subject: Re: [TLS] integrity only ciphersuites
On Mon, Aug 20, 2018 at 1:48 PM, Nancy Cam-Winget (ncamwing)
mailto:ncamwing=40cisco@dmarc.ietf.org>>
wrote:
All,
A couple IoT consortiums are trying to embrace the improvements made to T
On Mon, Aug 20, 2018 at 1:48 PM, Nancy Cam-Winget (ncamwing) <
ncamwing=40cisco@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
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
28 matches
Mail list logo
