On Tue, Aug 30, 2022 at 02:11:57PM +0200, Bas Westerbaan wrote:
> For TLS on the Web it would be ideal if we can find a single[1] hybrid
> which we can all be happy with because that will make keyshare
> negotiation easier.
I don't suppose that will happen, as:
- Some folks want something with P3
For TLS on the Web it would be ideal if we can find a single[1] hybrid
which we can all be happy with because that will make keyshare negotiation
easier.
To wit, BoringSSL, when SSL_OP_CIPHER_SERVER_PREFERENCE is set, will pick
the group based on the supported_groups that the client sends.
Thus,
On 23/08/2022 01:39, Martin Thomson wrote:
On Tue, Aug 23, 2022, at 00:11, Kris Kwiatkowski wrote:
As X25519 is not FIPS-approved, the lab won't be able to test it,
OK, hypothetical question, but maybe an important one.
Why would a certification lab care? We compose secrets with non-secrets
On Tue, Aug 23, 2022, at 00:11, Kris Kwiatkowski wrote:
> As X25519 is not FIPS-approved, the lab won't be able to test it,
OK, hypothetical question, but maybe an important one.
Why would a certification lab care? We compose secrets with non-secrets all
the time, so even if X25519 were replac
Dear, all,
On 22/08/2022 14:24, Bas Westerbaan wrote:
Here they're speaking about adding non-FIPS PQ to a non-PQ FIPS
kex,[2] but the other way around is also ok — what am I missing?
Let's assume Kyber is FIPS-approved. Indeed, you'll be able to have
a FIPS library with Z generated by Kyber a
On 22/08/2022 14:24, Bas Westerbaan wrote:
Here they're speaking about adding non-FIPS PQ to a non-PQ FIPS kex,[2] but
the other way around is also ok — what am I missing?
Let's assume Kyber is FIPS-approved. Indeed, you'll be able to have
a FIPS library with Z generated by Kyber and T generat
>
> Ultimately, I want fewer choices, but the direction the discussion is
> headed seems about right. At least in the short term, I think we need to
> eschew compression and only include one offer.
I also prefer fewer choices initially.
The only reason we're testing both X25519+Kyber512 and X25
On 19/08/2022 15:05, Salz, Rich wrote:
If it's a framework, and the framework seems to work for known
algorithms, then let's just publish the framework and add specifics
later.
I didn't conclude that the framework works so I'd
be against publishing now. (I do still need to
respond to the recen
If it's a framework, and the framework seems to work for known algorithms, then
let's just publish the framework and add specifics later.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Thu, Aug 18, 2022, at 7:57 PM, Martin Thomson wrote:
> On Thu, Aug 18, 2022, at 22:39, Scott Fluhrer (sfluhrer) wrote:
>> Actually, that was our original intention with this draft - to specify
>> the framework, and to have other documents specify the actual pairs.
>> However, I believe that t
On Thu, Aug 18, 2022, at 22:39, Scott Fluhrer (sfluhrer) wrote:
> Actually, that was our original intention with this draft - to specify
> the framework, and to have other documents specify the actual pairs.
> However, I believe that the sense of the working group is that they
> want this draft
> -Original Message-
> From: TLS On Behalf Of Martin Thomson
> Sent: Wednesday, August 17, 2022 7:05 PM
> To: tls@ietf.org
> Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
>
> On Sat, Aug 13, 2022, at 04:13, Scott Fluhrer (sfluhrer) wrote:
> > Well,
On Sat, Aug 13, 2022, at 04:13, Scott Fluhrer (sfluhrer) wrote:
> Well, if we were to discuss some suggested hybrids (and we now know the
> NIST selection), I would suggest these possibilities:
>
> - X25519 + Kyber512
> - P256 + Kyber512
> - X448 + Kyber768
> - P384 + Kyber768
Any specific pairs
those situations where we need to limit the message size (perhaps DTLS and
QUIC).
Is the working group happy with that?
-Original Message-
From: TLS On Behalf Of Ilari Liusvaara
Sent: Saturday, August 13, 2022 11:12 AM
To: TLS@ietf.org
Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-d
Ilari Liusvaara
Sent: Saturday, August 13, 2022 11:12 AM
To: TLS@ietf.org<mailto:TLS@ietf.org>
Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
On Fri, Aug 12, 2022 at 06:13:38PM +, Scott Fluhrer (sfluhrer) wrote:
Again, this is late, however Stephen did ask this to be discuss
s the working group happy with that?
-Original Message-
From: TLS <mailto:tls-boun...@ietf.org> On Behalf Of
Ilari Liusvaara
Sent: Saturday, August 13, 2022 11:12 AM
To: TLS@ietf.org<mailto:TLS@ietf.org>
Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
On Fri, A
urday, August 13, 2022 11:12 AM
To:TLS@ietf.org
Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
On Fri, Aug 12, 2022 at 06:13:38PM +, Scott Fluhrer (sfluhrer) wrote:
Again, this is late, however Stephen did ask this to be discussed in the
working group, so here we go:
-Original Me
rhaps DTLS and
QUIC).
Is the working group happy with that?
> -Original Message-
> From: TLS On Behalf Of Ilari Liusvaara
> Sent: Saturday, August 13, 2022 11:12 AM
> To: TLS@ietf.org
> Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
>
> On Fri, Aug 12, 2022
Saturday, April 30, 2022 11:49 AM
> > To: Ilari Liusvaara ; TLS@ietf.org
> > Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
> >
> >
> > Hiya,
> >
> > On 30/04/2022 10:05, Ilari Liusvaara wrote:
> > > On Sat, Apr 30, 2022 at 01:24:58AM
Again, responding to old emails...
> -Original Message-
> From: TLS On Behalf Of Stephen Farrell
> Sent: Friday, April 29, 2022 8:25 PM
> To: TLS@ietf.org
> Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
>
> - section 2: if "classic" DH were bro
Why both X25519+Kyber512 and P256+Kyber512?
Because there are good HW implementations supporting P256, and (at least for
some people) it’s good enough?
smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https:/
Why both X25519+Kyber512 and P256+Kyber512?
Note that Anything+Kyber512, in particular X25519+Kyber512, will be FIPS
certifiable after NIST standardized Kyber512.*
Best,
Bas
—
* With the tiny caveat that apparently the order of the shares does matter
atm. [insert facepalm.]
> - X25519 + Kyb
Again, this is late, however Stephen did ask this to be discussed in the
working group, so here we go:
> -Original Message-
> From: TLS On Behalf Of Stephen Farrell
> Sent: Saturday, April 30, 2022 11:49 AM
> To: Ilari Liusvaara ; TLS@ietf.org
> Subject: Re: [TLS] WGLC
Sorry for the late response; I was going through old emails and came across
this; I thought it warranted a response
> -Original Message-
> From: TLS On Behalf Of Ilari Liusvaara
> Sent: Saturday, April 30, 2022 5:05 AM
> To: TLS@ietf.org
> Subject: Re: [TLS] WGLC for
Hi folks,
Thanks to everyone who contributed to this WGLC! Based on the feedback
received, and given that our plan was to park this draft based on the outcome
of this WGLC, we'll keep this draft in the WG until the remaining work --
including codepoint allocation [1] -- is done.
Best,
Chris, f
I have reviewed the I-D and I agree with others that it is a simple
solution and that will benefit implementation. I have only a few
minor comments on the text.
- Section 1.2, definition of "Hybrid" should clarify that the key
exchange algorithms are to be performed (negotiated and transmitted,
a
Hi,
Thanks for this draft, which I found interesting and readable. I think it lays
out the problem well and proposes a conceptually straightforward solution that
will hopefully be less prone to implementation errors than more complex
options. However, there are a few points that I think need
Hiya,
Just on this one point:
On 02/05/2022 10:58, Ilari Liusvaara wrote:
Furthermore the extension involved (key_share) REALLY SHOULD NOT
differ between inner and outer hello.
I kinda agree, but the ECH spec allows 'em to differ.
In any case, the main point here is that this compression
is
I also don't like "WGLC-then-park" It's not a common workflow. Folks are
bound to get confused. I was. :)
So in terms of the WGLC, then, I object because this document is not ready (due
to external circumstances).
___
TLS mailing list
TLS@ietf.org
On Sat, Apr 30, 2022 at 04:48:59PM +0100, Stephen Farrell wrote:
>
> On 30/04/2022 10:05, Ilari Liusvaara wrote:
> > On Sat, Apr 30, 2022 at 01:24:58AM +0100, Stephen Farrell wrote:
> > >
> > > On 27/04/2022 16:27, Christopher Wood wrote:
> > > > This email commences a two week WGLC for draft-iet
> On Apr 29, 2022, at 8:24 PM, Stephen Farrell
> wrote:
>
> On 27/04/2022 16:27, Christopher Wood wrote:
>> This email commences a two week WGLC for draft-ietf-tls-hybrid-design,
>> located here:
>>https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
>
> As I guess I've said b
Hiya,
On 30/04/2022 10:05, Ilari Liusvaara wrote:
On Sat, Apr 30, 2022 at 01:24:58AM +0100, Stephen Farrell wrote:
Hiya,
On 27/04/2022 16:27, Christopher Wood wrote:
This email commences a two week WGLC for draft-ietf-tls-hybrid-design, located
here:
https://datatracker.ietf.org/doc/
On Sat, Apr 30, 2022, at 00:24, Douglas Stebila wrote:
> 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
>>>
On Sat, Apr 30, 2022 at 01:24:58AM +0100, Stephen Farrell wrote:
>
> Hiya,
>
> On 27/04/2022 16:27, Christopher Wood wrote:
> > This email commences a two week WGLC for draft-ietf-tls-hybrid-design,
> > located here:
> >
> > https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
>
Hiya,
On 27/04/2022 16:27, Christopher Wood wrote:
This email commences a two week WGLC for draft-ietf-tls-hybrid-design, located
here:
https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
As I guess I've said before, I think progressing this draft
now, even with this WGLC-the
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
Ah, got it. You're saying the Reference column would allow us to introduce
other combination methods if needed, through separate defining documents.
That sounds good to me as an upgrade path. Thanks!
On Thu, 28 Apr 2022 at 22:29, David Benjamin wrote:
> I don't think the upgrade path needs any
I don't think the upgrade path needs any mention or changes. It's no
different from what we always do: allocate a new code point.
Now that we've removed all the in-protocol combinator schemes from the
early versions, what remains is simply *a* method for defining a NameGroup
out of a pile of KEMs.
I'd like to reiterate my suggestion: While for now there is concensus for
using concatenation to combine the two shared secrets, we should have a
clear upgrade path if we want to use other combination methods in the
future.
As Douglas notes here [1], the document does commit to concatenation as th
I found the introduction of KeyGen, Encaps, and Decaps to be underutilized. It
would require a little work, but I think that it would be better to describe a
method whereby you produce each of these functions by taking an ordered
collection of these functions (KeyGen[i], Encaps[i], and Decaps[i
40 matches
Mail list logo
