> On Sep 1, 2024, at 10:47 AM, Stephen Farrell
> wrote:
>
> Section 3.2 says there are two allowed ways to handle the same
> component algs being used in multiple key shares. However,
> doesn't ECH mean that additional possibilities exist? What
> should a client do in terms of re-use when using
My understanding from discussing with the TLS chairs is that they will
separately seek to have the existing drafts containing Kyber code points
updated to also include new code points for ML-KEM hybrids.
Douglas
> On Aug 13, 2024, at 5:37 PM, Andrei Popov
> wrote:
>
> I think it would make
Sure, we can do that; I've made an issue in Github to track that.
Douglas
> On Aug 13, 2024, at 6:38 AM, Thom Wiggers wrote:
>
> Hi,
>
> I think this is great and what better time to do this than with the
> publication of FIPS 203 this week.
>
> The one thing that remains is that there are
couple of years ago which I don't think were
>>> fully
>> addressed at the time. I suspect this is just a security proof issue - the
>> inclusion of the ciphertexts in the transcript hash should still protect
>> against
>> any actual attacks - and it's ent
dra...@ietf.org
>> Sent: Friday, April 5, 2024 9:24 PM
>> To: i-d-annou...@ietf.org
>> Cc: tls@ietf.org
>> Subject: [TLS] I-D Action: draft-ietf-tls-hybrid-design-10.txt
>>
>> Internet-Draft draft-ietf-tls-hybrid-design-10.txt is now available. It is a
>
It expired simply because there had not been any updates in six months, and
drafts automatically expire after 6 months. I'll be posting a new version
shortly to keep it alive.
Douglas
> On Apr 5, 2024, at 02:21, Wang Guilin
> wrote:
>
> Dear all, It seems that I have missed some updated i
Thanks for the feedback Martin. I see what you're getting at regarding
phrasing it in terms of KeyGen[i], Encaps[i], etc. This is a good point:
>> For a hybrid key exchange, the key_exchange field of a KeyShareEntry is the
>> concatenation of the key_exchange field for each of the constituent
On Jan 22, 2022, at 06:35, Nimrod Aviram wrote:
>
> > The nice thing about the hybrid draft is that it isn't a firm commitment to
> > any particular combination method.
> > It only suggests a method.
>
> That's not my understanding. My reading is that the draft prescribes a
> combination meth
function to be collision
>> resistant and the output length from HKDF-Expand to be of size at
>> least 256 bits (or as much as needed for the hash function to prevent
>> finding collisions).
>>
>> With that said, defense in depth is good. Does it help to h
Hello TLS working group,
We've posted a revised version of "Hybrid key exchange in TLS 1.3" [1]. Based
on revision requests from the last draft, the main change is removing the
unnecessary appendix of the past design considerations, and a few wording
changes.
Last September, Nimrod Aviram, Be
worthwhile combination.
Douglas
> On Aug 5, 2021, at 15:22, Dan Brown wrote:
>
>> -Original Message-
>> From: TLS On Behalf Of Douglas Stebila
>> We wanted to see if there is any further feedback on our draft "Hybrid key
>> exchange in TLS 1.3" .
Hi Eric,
The main motivation is that, in some cases, post-quantum signatures are larger
in terms of communication size compared to a post-quantum KEM, under the same
cryptographic assumption.
For example, the KEM Kyber (based on module LWE) at the 128-bit security level
has 800-byte public k
On Jul 7, 2021, at 09:26, Salz, Rich wrote:
>
> PQ OID's came up in the LAMPS working group, which seems to want to defer to
> NIST. You should maybe cross-post your note there.
Hi Rich,
Unless I'm mistaken, OIDs are relevant to TLS in the context of signatures, but
not key exchange; TLS def
e the potential and have the handshake fail. I see that the finalists
> have low enough error rates that this doesn't seem likely to be an issue in
> practice. Clients can always try again if they hit this specific problem.
> Ours already retries in a bunch of different failure c
Dear TLS working group,
We wanted to see if there is any further feedback on our draft "Hybrid key
exchange in TLS 1.3"
(https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/) and what steps
are required for it to advance further. We have not received any new feedback
from the workin
urity WG of the IETF.
>
> Title : Hybrid key exchange in TLS 1.3
> Authors : Douglas Stebila
> Scott Fluhrer
> Shay Gueron
> Filename: draft-ietf-tls-hybrid-design-02.t
s well publish a new revision of the I-D in the datatracker, too, since
> the current one is approaching its expiry.
>
> -Ben
>
> On Fri, Sep 25, 2020 at 10:16:01AM -0400, Douglas Stebila wrote:
> > Thanks! I've merged it in.
> >
> > On Fri, Sep 25, 2020 at
2020 at 12:04, Nimrod Aviram wrote:
>>
>> Sounds good to me.
>> I'm happy to send a PR making these changes, but couldn't find the
>> repository for the document.
>> Could you please point me to it?
>>
>> best,
>> Nimrod
>>
>>
&g
Given that all the finalists and alternate candidates have fixed
length shared secrets, and your observations on the potential for
timing attacks, I'm fine with dealing with only fixed length secrets,
removing the paragraph discussing the possibility for variable-length
shared secrets from the TLS
> On Wed, Feb 12, 2020 at 02:26:21PM -0500, Douglas Stebila wrote:
>> Dear TLS working group,
>>
>> We would like to request the working group adopt
>> draft-stebila-tls-hybrid-design, "Hybrid key exchange in TLS 1.3", as
>> a working group item. We have upda
On Feb 12, 2020, at 11:24 PM, Rob Sayre wrote:
>
> Would it be ok to add a rationale to the "Goals" section around backward
> compatibility? I'm not sure how the compatibility points will interact with
> downgrade attacks.
For now I don't think we're envisioning anything different on downgrade
Hi Martin,
Thanks for the suggestions. Indeed, happy to incorporate changes in framing,
tone, etc. to better reflect the purpose of the document.
> At a high level, I think that this would be easier if it were more clearly
> framed as *recommendations*, especially when it comes to the format o
Dear TLS working group,
We would like to request the working group adopt
draft-stebila-tls-hybrid-design, "Hybrid key exchange in TLS 1.3", as
a working group item. We have updated the draft based on feedback
we've received over the past few months, including from our
presentations at IETF 104 an
Thanks for the feedback, Martin!
> We did however discuss a few options that I don't see in the draft. The one
> I am most interested in has the (EC)DHE replaced by HKDF-Extract(classic, PQ)
> rather than classic || PQ.
Good suggestion, I've added it to the document for the next version;
https
s encapsulated anywhere in TLS, then that complexity
needs to incorporated somewhere, either already in compound NamedGroups or in
configuration of the parallel key share mechanism. As I mentioned above, we
thought that combinatorial explosion of NamedGroups was not the TLS 1.3 way.
Dear TLS mailing list,
We have posted an Internet-Draft
https://tools.ietf.org/html/draft-schanck-tls-additional-keyshare-00
for using an additional key share in TLS 1.3. The intended use case is to
provide support for transitional key exchange mechanisms in which both a
pre-quantum algorithm
e should compare this failure mode (which might cause two "partnered"
parties to not get the same exporter key) with the failure mode if we use the
same EKM for the whole session (which might cause more parties than we expect
to get the same exporter key). Fail-closed versus fail-open.
Do
Some of the discussions I've had with people about post-handshake client
authentication have raised the question of whether application traffic secrets
should be updated automatically upon post-handshake client authentication: the
thinking being that every change in context should be accompanied
With Hugo's analysis of the secure channel-like security afforded even when the
application key is used to encrypt non-application data, and as Cédric pointed
out to me the application key will be used to encrypt non-application data like
certain alert messages; so I think option 1 is a reasonab
On Jun 3, 2016, at 17:54, Joseph Salowey wrote:
>
> Unfortunately, the TLS record framing is not easily compatible with having
> multiple keys used simultaneously: because we encrypt the content type, it is
> not possible to use it to determine which key to use to decrypt. We examined
> a numb
On Oct 5, 2015, at 5:17 AM, Eric Rescorla wrote:
>
> The problem is that we don't know how to generically provide compression
> safely. To take a concrete example: HTTP2's solution to header compression,
> HPACK, is extremely limited compared to a generic compression system
> like gzip, LZ77, etc
On Sep 21, 2015, at 10:43 PM, Hubert Kario wrote:
>
>> I doubt anyone would really want to use any keys in the megabyte range
>> anyway. Post-quantum crypto research/experimentation for TLS & other
>> network protocols should really focus on systems with smaller keys.
>> Even if a giant-key schem
32 matches
Mail list logo
