LS/SCTP, and DTLS-SRTP, etc. can differ.
Cheers,
John
From: Eric Rescorla
Date: Thursday, 11 February 2021 at 18:31
To: John Mattsson
Cc: "TLS@ietf.org"
Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher
Suites
John,
Thanks for raising this topic I think
@ietf.org
Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher
Suites
On Thu, Feb 11, 2021 at 3:08 PM Jack Visoky
mailto:jmvis...@ra.rockwell.com>> wrote:
Hi Eric,
I don’t have numbers offhand but I will say that many platforms I have
experience with have some sort
: John Mattsson , "TLS@ietf.org"
Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher
Suites
On Thu, Feb 11, 2021 at 3:08 PM Jack Visoky wrote:
Hi Eric,
I don’t have numbers offhand but I will say that many platforms I have
experience with have
nks,
>
>
>
> --Jack
>
>
>
>
>
> *From:* Eric Rescorla
> *Sent:* Thursday, February 11, 2021 2:51 PM
> *To:* Jack Visoky
> *Cc:* John Mattsson ;
> TLS@ietf.org
> *Subject:* Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only
> Cipher
] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher
Suites
On Thu, Feb 11, 2021 at 11:13 AM Jack Visoky
mailto:jmvis...@ra.rockwell.com>> wrote:
Hi John, Eric,
Thanks for the input. We will certainly make some changes to the draft
regarding the inspection case. However, I can’t s
On Thu, Feb 11, 2021 at 11:13 AM Jack Visoky
wrote:
> Hi John, Eric,
>
>
>
> Thanks for the input. We will certainly make some changes to the draft
> regarding the inspection case. However, I can’t support removing the
> performance/latency information completely, as I have heard from those who
>
language on my own, or if the WG has a suggestion we can use that.
Thanks,
--Jack
From: TLS On Behalf Of Eric Rescorla
Sent: Thursday, February 11, 2021 12:30 PM
To: John Mattsson
Cc: TLS@ietf.org
Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher
Suites
John,
Thanks
r
from experts such as yourself and others on this list.
Thanks,
--Jack
-Original Message-
From: Stephen Farrell
Sent: Wednesday, February 10, 2021 9:48 PM
To: Jack Visoky ; TLS@ietf.org
Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher
Suites
Hiya,
F
John,
Thanks for raising this topic I think it's important. I agree with you on
the technical situation. As you say, we should be encouraging people to
move to TLS 1.3, and NULL encryption cipher suites do not provide all the
guarantees that TLS 1.3 is intended to deliver. [0].
I also agree with
Hi,
I agree with Bill. Keeping confidentiality in all TLS/1.3 connections is
future proofing.
Supposedly analyzing and then leaving confidentiality out invites future
attacks.
Cheers,
- Ira
On Thu, Feb 11, 2021 at 9:56 AM Bill Frantz wrote:
> On 2/11/21 at 9:01 PM, rsalz=40akamai@dmarc.i
On 2/11/21 at 9:01 PM, rsalz=40akamai@dmarc.ietf.org (Salz,
Rich) wrote:
I would just like to recognize that there are some situations where it isn't
needed.
Can you explain why TLS 1.2 isn't good enough for your needs?
In my experience, there are many attacks that aren't anticipated
Salz, Rich wrote:
>Can you explain why TLS 1.2 isn't good enough for your needs?
I think it's bad to force industries requiring visibility to use TLS 1.2 unless
it is for a limited time. TLS 1.2 is obsolete. I think the TLS WG should not
spend any more time on TLS 1.2.
I personally do not obj
On Thu, Feb 11, 2021 at 12:40:51AM -0200, Viktor Dukhovni wrote:
>
> There is merit in keeping the combinatorial complexity of TLS 1.3
> as small as possible, reducing implementation attack surface, ...
>
> The key question, that is difficult to answer is whether the right
> balance is adequately
that can be dangerous in unexpected and hard to analyse ways,
should they get widely deployed. (And I hope we've all
learned that undeploying these things is a big pile of
painful work, to put in very nicely:-)
Cheers,
S.
Thanks,
--Jack
-Original Message- From: Stephen Farrell
Sent
> On Feb 10, 2021, at 11:57 PM, Jack Visoky
> wrote:
>
> I would just like to recognize that there are some situations where it isn't
> needed.
One classic case where Postfix supports TLS 1.[0-2] NULL ciphers
is loopback TLS (process to process communication via [127.0.0.1]
or a unix-domain so
> I would just like to recognize that there are some situations where it isn't
> needed.
Can you explain why TLS 1.2 isn't good enough for your needs?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
to
recognize that there are some situations where it isn't needed.
Thanks,
--Jack
-Original Message-
From: Stephen Farrell
Sent: Wednesday, February 10, 2021 6:46 PM
To: Jack Visoky ; John Mattsson
; TLS@ietf.org
Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity onl
I also do not support this draft. Don't all of these proposals come with
claims about efficiency and latency? It's getting old. Sorry if that sounds
cynical.
thanks,
Rob
On Wed, Feb 10, 2021 at 1:15 AM John Mattsson wrote:
> Hi,
>
> - The draft has a lot of claims regarding benefits:
>
> "str
elieve experience so far has shown that to be the wisest
approach in general.
S.
Thanks,
--Jack
-Original Message- From: TLS On Behalf
Of Stephen Farrell Sent: Wednesday, February 10, 2021 7:08 AM To:
John Mattsson ;
TLS@ietf.org Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authenticatio
I oppose this draft. Use earlier versions of TLS that do have auth-only and
integrity cipher suites.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
S 1.3 Authentication and Integrity only Cipher
Suites
Hiya,
I realise it's not proposed as a wg document, but fwiw, I think John is quite
correct below. The only additional point I'd add is that I've seen cases over
the years where the fact that confidentiality really *is* required onl
tsson
Sent: Wednesday, February 10, 2021 4:15 AM
To: TLS@ietf.org
Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher
Suites
Hi,
- The draft has a lot of claims regarding benefits:
"strong requirement for low latency."
"minimize the cryptographic a
Hiya,
I realise it's not proposed as a wg document, but
fwiw, I think John is quite correct below. The only
additional point I'd add is that I've seen cases
over the years where the fact that confidentiality
really *is* required only became clear when people
actually considered how to attack sys
Hi,
- The draft has a lot of claims regarding benefits:
"strong requirement for low latency."
"minimize the cryptographic algorithms are prioritized"
"important for latency to be very low."
"pay more for a sensor with encryption capability"
"come with a small runtime memory footprint an
Visoky ;
Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher
Suites
Hardware support for AES but not SHA2 is extremely common. For devices without
acceleration, ChaCha20-Poly1305 is likely to be faster than SHA256 (e.g.
according to https://www.bearssl.org/speed.html
Hardware support for AES but not SHA2 is extremely common. For devices
without acceleration, ChaCha20-Poly1305 is likely to be faster than SHA256
(e.g. according to https://www.bearssl.org/speed.html).
Unless your device has hardware offload for SHA256 but _not_ for AES (a
rare combination), you
Ben Schwartz writes:
>If you are updating the text, I would recommend removing the claim about
>performance. In general, the ciphersuites specified in the text are likely
>to be slower than popular AEAD ciphersuites like AES-GCM.
Uhh... when is AES-GCM faster than SHA2, except on systems with h
If you are updating the text, I would recommend removing the claim about
performance. In general, the ciphersuites specified in the text are likely
to be slower than popular AEAD ciphersuites like AES-GCM.
On Fri, Feb 5, 2021 at 5:38 PM Jack Visoky wrote:
> Hi Ben,
>
>
>
> Thanks for the feedba
Hi Ben,
Thanks for the feedback, I think you have some good insights. I agree that
there are cases where mutual authentication is not required, we’ll update to
reflect that. Same for PSKs, on thinking about this there doesn’t seem to be a
good reason why PSKs cannot be used. We’ll make some upd
29 matches
Mail list logo
