Hi Nick,
Please see inline
On Wed, 16 Sep 2020 at 06:00, Nick Harper wrote:
> I agree with EKR, Ben Schwartz, and Watson Ladd's concerns on this draft.
>
> The grease_extension parameter shouldn't exist, and there should be no
> special handling for GREASE values. GREASE doesn't need to be ment
On Mon, Sep 14, 2020 at 11:11:03AM -0400, Daniel Migault wrote:
> Hi Nick,
>
> Thanks for the response and I apologize for my delayed response. However I
> still have two major concerns regarding the current proposed text:
>
> Mentioning keyless as the only solution complementary to DC still see
Dear all,
We are writing to ask about the possible security impact of
variable-length secrets on the "Hybrid key exchange in TLS 1.3" RFC
[1].
As you probably know, when using key material of variable length
and processing this material using hash functions, a timing side
channel may arise. In br
"Variable-length" and "secret" don't really go together in the same
sentence, as your work demonstrates. I would actually go further and strike
that text altogether. I don't think it needs to be an open question. That
lets us stick with a simple construction.
While the public values aren't secret
On Wed, Sep 16, 2020 at 12:47 PM David Benjamin
wrote:
> "Variable-length" and "secret" don't really go together in the same
> sentence, as your work demonstrates. I would actually go further and strike
> that text altogether. I don't think it needs to be an open question. That
> lets us stick wi
On Wed, Sep 16, 2020 at 07:26:56PM +0300, Nimrod Aviram wrote:
>
> We also note that a related RFC exists, "Hybrid Post-Quantum Key
> Encapsulation Methods (PQ KEM) for Transport Layer Security 1.2"
> [4]. However, that RFC apparently only uses BIKE, Kyber or SIKE as the
> PQ KEM. To our knowledge
On Sep 16, 2020, at 1:08 PM, Nick Harper
wrote:
> On Wed, Sep 16, 2020 at 12:24 AM tirumal reddy wrote:
> Hi Nick,
>
> Please see inline
>
> On Wed, 16 Sep 2020 at 06:00, Nick Harper wrote:
> I agree with EKR, Ben Schwartz, and Watson Ladd's concerns on this draft.
>
> The grease_extension p
Taking a step back from details, ISTM that the whole design of this
document is antithetical to extensibility:
TLS is a protocol with a number of extension points. What this document
does is allow an endpoint to restrict its use of a certain set of extension
points. However, the language provided h
