Hi Sean, Rich,
Thanks for the input, I'll take care of it.
Thanks,
--Jack
-Original Message-
From: Salz, Rich
Sent: Friday, March 15, 2019 12:50 PM
To: Sean Turner ; Jack Visoky
Cc: tls@ietf.org
Subject: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC
[Use caution with link
rrell
Sent: Monday, March 4, 2019 5:53 PM
To: Jack Visoky ; John Mattsson
Cc: tls@ietf.org
Subject: Re: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC
Jack,
(With the proviso that this isn't and I agree ought not be a WG item, so the
chairs should feel free to tell me to
stop...)
Jack,
(With the proviso that this isn't and I agree ought not
be a WG item, so the chairs should feel free to tell me to
stop...)
On 04/03/2019 21:49, Jack Visoky wrote:
> OK I will add an update to the draft which further emphasizes that
> these cipher suites are strictly to be used when confid
Hi John,
OK I will add an update to the draft which further emphasizes that these cipher
suites are strictly to be used when confidentiality is not a concern.
Yes good catch on the tag length for SHA-384, I’ll also update that to 48, that
appears to be a typo.
Thanks,
--Jack
From: John Matts
Hi Jack,
>I’d expect that there are cases where authenticated encryption would be just
>as performant, but I’m sure there are cases where just SHA-256 HMAC is more
>performant.
This is what I would expect for the current cipher suites with GCM and CCM.
Newer AEAD algorithms such as AEGIS (in
Hi John,
Messages in this category of communications range in size from a couple of
bytes to around a hundred or so (I suppose there could be even larger messages
but that would be pretty uncommon). Platforms range quite a bit, but I would
say some flavor of ARM is pretty common, with either n
Hi Eric (and others),
Thanks for the feedback on this. I’ll need to talk with Nancy but I think it’s
become pretty clear that this draft should not become a TLS-WG item. That
said, I appreciate the feedback thus far and welcome further discussion from
those in this group.
Thanks,
--Jack
Fr
On 28/02/2019 13:54, Salz, Rich wrote:
> * Obviously, individuals should feel free to review this document or not
> as they please, but I'm not seeing any compelling reason why TLS-WG should
> take it on
>
> +1 to all EKR said.
Same here.
S
>
>
> __
* Obviously, individuals should feel free to review this document or not as
they please, but I'm not seeing any compelling reason why TLS-WG should take it
on
+1 to all EKR said.
The meaning of TLS has gotten stronger over the years, and TLS now implies
privacy. Auth-only is not something
Jack,
There's a bunch here to unpack.
First, the purpose of the current registry structure was to allow code
point registration without forcing the TLS WG to spend time on documents
that don't generally meet its goals. This seems like one such document.
WRT to your points about the benefits of R
Hi Eric,
Our goal is to have an RFC published as Informational and with the Not
Recommended status. We felt having this approved through the IETF process vs
just ISE would be beneficial to those wishing to adopt, and getting community
review is also helpful to us and those we represent.
I sup
Hi David,
Thanks for sharing this, although the strong preference is to use standard TLS
for securing the communications.
Thanks,
--Jack
-Original Message-
From: TLS On Behalf Of David Wong
Sent: Tuesday, February 26, 2019 5:54 PM
To: Hanno Böck
Cc:
Subject: EXTERNAL: Re: [TLS] Aut
Hi Hanno,
No, the tests have not been published. I can look at trying to make this data
publicly available but I cannot guarantee that.
Tests were generally done with AES and SHA hashing. One reason for this is
that many in this industry have incorporated some hardware-based crypto
accelerat
Hi,
On Tue, 26 Feb 2019 21:26:45 +
Jack Visoky wrote:
> We have done tests on this and it there is a difference.
Have these tests in any way been published? Because otherwise it's a
very weak argument.
There are some obvious questions, e.g.:
* What algorithm implementation was tested, was
FWIW I tend to agree with Hanno. Sending this to the ISE is
likely better if an RFC is even needed. We already opened up
the ciphersuite registration process to allow this kind of
thing without the WG having to try (and sometimes fail to)
reach rough consensus on things like this.
On 26/02/2019 2
Hi Hanno,
We have done tests on this and it there is a difference. For some industries
(industrial automation) throughput is very sensitive so what might appear as a
small difference can actually be quite significant. On that same note, yes you
are absolutely correct that the asymmetric hands
16 matches
Mail list logo
