On 10/2/20 14:15, I wrote:
The server also needs to know the entire HelloRetryRequest message
since this goes into the Transcript Hash calculation:
Transcript-Hash(ClientHello1, HelloRetryRequest, ... Mn) =
Hash(message_hash ||/* Handshake type */
00 00 Hash.length
Hi folks,
Below are two issues we can probably resolve before publishing -08 of ECH.
Proposed resolutions in the form of a PR accompany each issue. Please have a
look and let us know if you support the proposed resolutions, and, if not,
please indicate what you think should be done differently.
Hi!
I've assumed the role of responsible AD on this document. As such, I performed
an AD review of draft-ietf-tls-md5-sha1-deprecate-03.
Thanks for writing this document to address an important crypto maintenance
tasks in TLS v1.2. I have a few clarifying and pro forma editorial items of
f
> If the client is trying to perform
> some sort of attack on the server by re-sending an old cookie, I assume
> that a prerequisite for this attack is that the TLS handshake succeeds.
Maybe you don't need the handshake to succeed? As a non-cryptographer
I can't say what the implications might
> > You can't possibly implement [stateless HelloRetryRequest] the
> > way the spec suggests with just a hash in a HRR cookie extension.
>
> The only thing the server needs to know is the hash of the ClientHello
> (so it can restore the transcript hash) and that the server has already
> sent a
On Fri, Oct 2, 2020 at 10:11 PM Loganaden Velvindron
wrote:
>
> Please go ahead. I remembered a discussion (outside of the ietf) where
> not everybody agreed
> with it but reluctantly implemented it.
>
Found the commit message in LibreSSL:
"
Reluctantly add server-side support for TLS_FALLBACK_
Please go ahead. I remembered a discussion (outside of the ietf) where
not everybody agreed
with it but reluctantly implemented it.
On Fri, Oct 2, 2020 at 9:44 PM Sean Turner wrote:
>
>
>
> > On Sep 23, 2020, at 08:43, Sean Turner wrote:
> >
> > Hi! this issue was buried in the Ben’s review, but
> On Sep 23, 2020, at 08:43, Sean Turner wrote:
>
> Hi! this issue was buried in the Ben’s review, but I think it is worth
> getting some attention on.
>
>> On Aug 13, 2020, at 13:54, Benjamin Kaduk wrote:
>>
>> On Wed, Aug 12, 2020 at 04:29:56PM -0400, Kathleen Moriarty wrote:
>>>
>>> On
A new meeting session request has just been submitted by Christopher A. Wood, a
Chair of the tls working group.
-
Working Group Name: Transport Layer Security
Area Name: Security Area
Session Requester: Christopher Wood
Number of Sessi
The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Exported Authenticators in TLS'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive c
Hi!
I've assumed the role of responsible AD on this document. As such, I performed
an AD review of draft-ietf-tls-exported-authenticator-13. This document has
seen a few WG LCs and reviews. Thanks for working out the details for this
feedback.I have a few questions and suggestions for pr
11 matches
Mail list logo
