It seems to me like the next step is to share a paper, ideally in the form of
an internet-draft, that describes more precisely what you would like to see
happen.
On Wed, May 26, 2021, at 18:48, Florian Wilkens wrote:
> Dear all,
>
> first, we want to thank you for your feedback, it is much appr
Dear all,
first, we want to thank you for your feedback, it is much appreciated!
We wanted to briefly clarify some details about our idea:
- AEAD/non-AEAD: completely true. We were mainly looking at ciphers from
TLS 1.3 that all use keys and IVs but that is of course unrelated to
AEAD as a concep
Am Montag, dem 17.05.2021 um 16:04 -0500 schrieb Darin Pettis:
> Hi Stephen,
> Thanks for the quick reply as I know it is getting late in Ireland.
>
> I’m sure you do remember the conversation as you spent a lot of time
> at the microphone around it. :-)
>
> It is certainly not an easy question
Hi Stephen,
Thanks for the quick reply as I know it is getting late in Ireland.
I’m sure you do remember the conversation as you spent a lot of time at the
microphone around it. :-)
It is certainly not an easy question to answer but this group comprises the
smartest people that I know!! Surely
On Mon, May 17, 2021 at 1:33 PM Darin Pettis
wrote:
> Thanks to Eric and Rich for your technical responses and cautionary
> statements.
>
> I do see that Florian’s use-case below points to the continued need for
> enterprise inspection as once the data lands inside the data center they
> become t
Hiya,
On 17/05/2021 21:33, Darin Pettis wrote:
TLS 1.3 did a great job regarding safety of data on the Internet. For the
next version, let’s focus on how to best meet this used case
I think we had this discussion a few years ago. There is
no sensible boundary at which TLS can apply different
…use case*
Thanks in advance,
Darin Pettis
On Mon, May 17, 2021 at 3:33 PM Darin Pettis
wrote:
> Thanks to Eric and Rich for your technical responses and cautionary
> statements.
>
> I do see that Florian’s use-case below points to the continued need for
> enterprise inspection as once the data
Thanks to Eric and Rich for your technical responses and cautionary
statements.
I do see that Florian’s use-case below points to the continued need for
enterprise inspection as once the data lands inside the data center they
become the custodians of it and are responsible for the security and
perf
Hi Florian,
This suggestion comes up occasionally, and as Rich Salz says,
you could just register your own cipher suite.
With that said, I would make three comments:
1. I think it's a bit of a category error to talk about AEAD versus
non-AEAD in this context. AEAD is just an interface, so it's p
Without commenting on the use-case itself, I am concerned that people will not
appreciate "drop AEAD and its assurance of authenticity" would now also mean
"can be passively monitored."
I will point out that anyone can publish write a draft and request numbers to
be assigned (e.g., look for GO
Hey folks,
we came across a novel use-case that highlights the need for non-AEAD
ciphers in TLS and would like to start a discussion on that.
Our use-case is passive TLS decryption on network monitors (NMs).
Non-AEAD ciphers would allow to selectively forward the TLS write keys
from clients to a
11 matches
Mail list logo
