I am also against adoption.
I would not be against a draft that made deployment recommendations, if
RFC 9325 was considered insufficient. (Although I don't like the idea of
suggesting that TLS 1.2 without support for quantum-resistant
cryptography is a recommended long-term solution.) However,
Hiya,
On 06/11/2024 19:00, Salz, Rich wrote:
I still dislike encouraging private discussion of drafts - that's
not really in the spirit of the IETF at all.
While you're talking spirit versus letter of the rules, it is
explicitly allowed
Yes.
Just to note there's also the option to have a
> I still dislike encouraging private discussion of
> drafts - that's not really in the spirit of the
> IETF at all.
While you're talking spirit versus letter of the rules, it is explicitly
allowed in RFC 2418, https://www.rfc-editor.org/rfc/rfc2418.html#page-19: In
order for a design team to re
On Wed, Nov 6, 2024 at 10:00 AM Stephen Farrell
wrote:
>
> The process/description is getting better thanks.
>
Yes, agree.
>
> Using the term liaison will confuse people so be
> better to change that.
>
Yep, it's correct English/French, but it has an IETF meaning that is more
specialized. But
Hiya,
On 05/11/2024 15:34, Joseph Salowey wrote:
There is an updated FATT available here:
https://github.com/tlswg/tls-fatt
This has taken a lot of the feedback we have received so far, but is still
a work in progress. There will be a little time to discuss in the meeting
Friday.
The process
I do not support adoption.
Best,
Chris
> On Nov 5, 2024, at 11:25 AM, Sean Turner wrote:
>
> REQUEST: Let’s not rehash all the context. It is provided for those who
> might not remember or those that were not around for the duration.
>
> CONTEXT: Way back in 2016 after the WG had embarked o
I concur with everything Nick says here.
Deployment guidance is fine. We should not adopt any document that would
require code changes to implement.
We should not adopt this document in its current form.
--Richard
On Tue, Nov 5, 2024 at 7:49 PM Nick Harper wrote:
> I understand the stated go
I do not support adoption.
On Tue, Nov 5, 2024 at 5:27 PM Sean Turner wrote:
> REQUEST: Let’s not rehash all the context. It is provided for those who
> might not remember or those that were not around for the duration.
>
> CONTEXT: Way back in 2016 after the WG had embarked on developing TLS 1
👍👍
On Wed, Nov 6, 2024 at 7:34 AM John Mattsson
wrote:
> Hi Deirdre,
>
>
>
> I think it would be good to give developers and users an idea of how small
> the failure rate is. They might not understand what “cryptographically
> small failure rate” is.
>
>
>
> OLD: "ML-KEM has a cryptographically
Arnaud Taddei writes:
>There is a big difference between
>
>patching an endpoint to a variation of TLS1.2 which is meant to work in a ’
>TLS1.2 designed environment”
>
>Vs
>
>patching an endpoint to TLS1.3 in an environment that was ’TLS1.2 designed
>environment’
Yup, and that's the intent of the
Hi Peter
I've never seen TLS 1.3 in an embedded device. By "embedded device" do you
>
mean a Linux box, or something running RTEMS, uC/OS, ThreadX, or similar?
>
TLS 1.3 in PSK mode for secure element (smartcard) is described in
https://datatracker.ietf.org/doc/draft-urien-tls-se/
Implementati
On Tue, Nov 5, 2024, at 16:25, Sean Turner wrote:
> MESSAGE: This message is to judge consensus on whether there is support
> to adopt TLS 1.2 Update for Long-term Support;
https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls12-frozen-02 says:
"no new features will be approved for TLS 1.2"
On Tue, Nov 05, 2024 at 07:01:13PM +, Salz, Rich wrote:
> I strongly support adoption.
>
> I do not understand why anyone would be opposed to the IETF making
> deployment recommendations. I can understand why someone might be
> bothered by the impliciation that *THIS ONE WAY* is the only way
Eric Rescorla writes:
>it's effectively a new version of TLS with as yet only lightly analyzed
>security properties.
Are you sure you've read the right document? "A new version of TLS"? It's
existing extensions, a few minor tweaks to deal with long-known problem areas,
and some implementation
Watson Ladd writes:
>TLS 1.3 has widely been implemented and depoloyed across embedded devices and
>has much better analysis. You'd still need to patch devices for this to be
>deployable.
I've never seen TLS 1.3 in an embedded device. By "embedded device" do you
mean a Linux box, or something r
Nick Harper writes:
>If endpoints need to be updated to support TLS-LTS, it would make more sense
>to update them to support TLS 1.3 than TLS-LTS.
The difference is that TLS 1.3 requires a complete new protocol stack while
the draft is a minimal tweak to a few known problem areas in TLS 1.2 whil
On Sun, 3 Nov 2024 at 14:12, Ilari Liusvaara
wrote:
> On Sun, Nov 03, 2024 at 05:37:34AM +0530, tirumal reddy wrote:
> >
> > The draft
> https://datatracker.ietf.org/doc/draft-tls-reddy-composite-mldsa/
> > specifies how ML-DSA in combination with traditional algorithms can be
> used
> > for auth
Hi Deirdre,
I think it would be good to give developers and users an idea of how small the
failure rate is. They might not understand what “cryptographically small
failure rate” is.
OLD: "ML-KEM has a cryptographically small failure rate"
NEW: "ML-KEM has a cryptographically small failure rate
On Mon, 4 Nov 2024 at 19:47, Alicja Kario wrote:
> Hello,
>
> I don't think we should go back to signing with PKCS#1 v1.5 in TLSv1.3.
> I'm opposed to including those two IDs:
>
> mldsa44_rsa_pkcs1_sha256 (0x090C),
> mldsa65_rsa_pkcs1_sha384 (0x090D),
>
I wanted to remove them but I
Hi all,
I don’t think that we should consider saying that TLS 1.2 (or a variant) is an
okay and safe choice for the next 10+ years while this protocol will not
receive post-quantum security updates (if we stick with “no PQ for TLS 1.2”). I
realize that integrating PQC in a “LTS” deployment migh
I am against adoption.
As Nick and Watson note, this is not just a profile of TLS 1.2 but is
rather a set of negotiated with a new extension code point, i.e., it's
effectively a new version of TLS with as yet only lightly analyzed security
properties. We already have a new version of TLS which has
I do support the adoption of this draft.
This draft is a very good product and the details and care that this draft
exhibits is in itself a testimony of someone who has a real production
experience, is realistic and pragmatic.
There is a big difference between
patching an endpoint to
To clarify here,
You can't have a reference here to " A "permanent" Design Group for TLS".
That term is wrong and confusing.
I don't disagree with all of the rest, which has changed since the last
round, but that does need to be fixed up.
Maybe Rich doesn't want to update his draft, but that nee
I'm against adoption. TLS 1.3 has widely been implemented and
depoloyed across embedded devices and has much better analysis. You'd
still need to patch devices for this to be deployable.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email t
I understand the stated goal of this draft to be to provide a way for
hard-to-update endpoints to keep using TLS 1.2 in a secure way. The idea of
a document that describes how to safely deploy TLS 1.2 sounds like a good
idea, e.g. "use only these cipher suites, require EMS and RI, etc". This
draft
On Tue, Nov 05, 2024 at 03:24:16PM +, David Benjamin wrote:
> On Tue, Nov 5, 2024 at 2:25 PM Ilari Liusvaara
> wrote:
>
> > There is WG draft for Extended Key Update. That can be initiated from
> > either side, needs at least three flights (and the current version has
> > four flights) and pr
* I think Rich should retitle his document to "A 'permanent' Design Team
for TLS", but then we can get on with it.
I think my draft served my intended purpose, and while I prefer design team
over FATT, I don’t see a reason to push forward on my draft any more. (And
thanks for the nice word
I strongly support adoption.
I do not understand why anyone would be opposed to the IETF making deployment
recommendations. I can understand why someone might be bothered by the
impliciation that *THIS ONE WAY* is the only way to get long-term support,
especially if it's seen to contradict our
I do not support adoption.
On Tuesday, 5 November 2024 17:25:16 CET, Sean Turner wrote:
REQUEST: Let’s not rehash all the context. It is provided for
those who might not remember or those that were not around for
the duration.
CONTEXT: Way back in 2016 after the WG had embarked on
developin
On Tue, Nov 5, 2024 at 8:25 AM Sean Turner wrote:
> REQUEST: Let’s not rehash all the context. It is provided for those who
> might not remember or those that were not around for the duration.
>
> CONTEXT: Way back in 2016 after the WG had embarked on developing TLS 1.3,
> Peter Gutmann suggeste
I think Rich should retitle his document to "A 'permanent' Design Team for
TLS", but then we can get on with it.
The title is confusing because the first sentence is:
"This memo defines a permanent design team, as defined in [WGPROCS],"
That's a nit, but I think we want to be clear no process is
> On Nov 5, 2024, at 16:25, Sean Turner wrote:
>
> REQUEST: Let’s not rehash all the context. It is provided for those who
> might not remember or those that were not around for the duration.
>
> CONTEXT: Way back in 2016 after the WG had embarked on developing TLS 1.3,
> Peter Gutmann sugg
On Tue, Nov 5, 2024 at 2:25 PM Ilari Liusvaara
wrote:
> On Tue, Nov 05, 2024 at 11:47:44AM +, David Benjamin wrote:
> > On Mon, Nov 4, 2024 at 5:19 PM Ilari Liusvaara >
> > wrote:
> >
> > >
> > > If the blocking flight has response, then explicit ACK is required to
> > > avoid deadlock (to g
On Tue, Nov 05, 2024 at 11:47:44AM +, David Benjamin wrote:
> On Mon, Nov 4, 2024 at 5:19 PM Ilari Liusvaara
> wrote:
>
> >
> > If the blocking flight has response, then explicit ACK is required to
> > avoid deadlock (to get out of state where both sides have flight in
> > progress). But this
On Mon, Nov 4, 2024 at 5:19 PM Ilari Liusvaara
wrote:
> > > There is subtle edge case where this can cause outright failures:
> > >
> > > - Sender that implements only linear tracking.
> > > - Very large flight that gets split into lots of records.
> > > - Some of those records get evicted from A
On Sun, 3 Nov 2024 at 14:34, Ilari Liusvaara
wrote:
> On Sun, Nov 03, 2024 at 05:45:13AM +0530, tirumal reddy wrote:
> >
> > This draft https://datatracker.ietf.org/doc/draft-tls-reddy-slhdsa/
> > specifies how the PQC signature scheme SLH-DSA can be used for
> > authentication in TLS 1.3.
>
> I
e_algorithms.
Yes, I’m surprised but at no point am I suggesting that SLH-DSA
should be withheld, just that the draft should be explicit about
what is or is not being proposed. The conditional in the final
quote is fairly important.
Thanks,
Peter
From: Bas Westerbaan
Sent: 04 November 2024
>> not recommended for use in signature_algorithms
>
> People deploying TLS can do the performance measurements for themselves
> and decide whether high confidence in security is affordable for their
> applications. Shouldn't speed be given lower weight than security in
> decisions of what to rec
On Mon, Nov 4, 2024 at 6:31 PM D. J. Bernstein wrote:
> Speaking for myself, not on behalf of the SPHINCS+ team (or other teams
> potentially relevant here).
>
> Peter C writes:
> > Under realistic network conditions, TLS handshakes with full SLH-DSA
> > certificate chains seem to be about 5-10 t
Speaking for myself, not on behalf of the SPHINCS+ team (or other teams
potentially relevant here).
Peter C writes:
> Under realistic network conditions, TLS handshakes with full SLH-DSA
> certificate chains seem to be about 5-10 times slower than traditional
> certificate chains and, in some case
On Mon, Nov 04, 2024 at 01:52:06PM +, David Benjamin wrote:
> On Sun, Nov 3, 2024 at 3:50 PM Ilari Liusvaara
> wrote:
>
> > On Sun, Nov 03, 2024 at 12:49:59PM +, David Benjamin wrote:
> >
>
> The spec also recommends you keep your older epochs around for a spell in
> case of packet reord
Monday, November 4, 2024 2:16 AM
To: Peter C
Cc: IETF TLS
Subject: [EXTERNAL] [TLS] Re: New Version Notification for
draft-tls-reddy-slhdsa-00.txt
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and kn
On Mon, Nov 4, 2024 at 8:25 AM Sean Turner wrote:
>
> > On Nov 4, 2024, at 15:35, Joseph Salowey wrote:
> >
> > On Mon, Nov 4, 2024 at 10:48 AM Salz, Rich wrote:
> > > While there is overlap between professional behavior and the perceived
> focus on browser specific use cases; I think we should
> On Nov 4, 2024, at 15:35, Joseph Salowey wrote:
>
> On Mon, Nov 4, 2024 at 10:48 AM Salz, Rich wrote:
> > While there is overlap between professional behavior and the perceived
> > focus on browser specific use cases; I think we should try to separate out
> > the topic.
>
> My memory, per
On Mon, Nov 4, 2024 at 10:48 AM Salz, Rich wrote:
> > While there is overlap between professional behavior and the perceived
> focus on browser specific use cases; I think we should try to separate out
> the topic.
>
> My memory, perhaps faulty, is that "will browsers implement this" has been
> a
Hello,
I don't think we should go back to signing with PKCS#1 v1.5 in TLSv1.3.
I'm opposed to including those two IDs:
mldsa44_rsa_pkcs1_sha256 (0x090C),
mldsa65_rsa_pkcs1_sha384 (0x090D),
Theoretically we could require the RSA part to still make PSS signatures
but I think that would b
Hi! This is just another reminder that this WG adoption call is still ongoing.
spt
> On Oct 25, 2024, at 03:46, Sean Turner wrote:
>
> At the TLS meeting at IETF 119 we discussed the Large Record Sizes for TLS
> and DTLS I-D; see [0] and [1]. There has been some list discussion; see [2]
> and
ecessairly.
Peter
From: tirumal reddy
Sent: 04 November 2024 07:16
To: Peter C
Cc: IETF TLS
Subject: Re: [TLS] Re: New Version Notification for
draft-tls-reddy-slhdsa-00.txt
Hi Peter,
Please see inline
On Sun, 3 Nov 2024 at 22:17, Peter C wrote:
Tiru,
Is SLH-DSA considered a prac
On Sunday, 3 November 2024 22:22:52 CET, Peter C wrote:
John Mattsson wrote:
”Conversely, the fast version prioritizes speed over
signature size, minimizing the time required to generate
and verify signatures.”
This is incorrect. The “f” versions only have faster key
generation and signing. The
On Sun, Nov 3, 2024 at 3:50 PM Ilari Liusvaara
wrote:
> On Sun, Nov 03, 2024 at 12:49:59PM +, David Benjamin wrote:
> > Hi all,
> >
> > So, Section 7 says the ACK contains:
> > > A list of the records containing handshake messages in the current
> flight
> > which the endpoint has received an
used for both extensions, so
if you are not proposing SLH-DSA end-entity certificates then you need to be
more explicit that it is not recommended for use in signature_algorithms.
Peter
From: tirumal reddy
Sent: 04 November 2024 07:16
To: Peter C
Cc: IETF TLS
Subject: Re: [TLS] Re: New Version N
> While there is overlap between professional behavior and the perceived focus
> on browser specific use cases; I think we should try to separate out the
> topic.
My memory, perhaps faulty, is that "will browsers implement this" has been a
process-gating question in the past. Recognizing that
On Mon, 4 Nov 2024 at 02:52, Peter C wrote:
> John Mattsson wrote:
>
> > ”Conversely, the fast version prioritizes speed over
>
> > signature size, minimizing the time required to generate
>
> > and verify signatures.”
>
> >
>
> > This is incorrect. The “f” versions only have faster key
>
> > gen
day, 3 November 2024 at 17:49
> *To: *tirumal reddy
> *Cc: *IETF TLS
> *Subject: *[TLS] Re: New Version Notification for
> draft-tls-reddy-slhdsa-00.txt
>
> Tiru,
>
>
>
> Is SLH-DSA considered a practical option for TLS end-entity certificates?
>
>
>
> U
In support of this draft, some basic formal analysis of a widely-used
variant of attested TLS (namely Intel's RA-TLS) has already been done
[1]. Unfortunately, Intel did not specify any properties. Also, RFC9334
is super vague about security properties. We, therefore, kindly ask the
WG for feed
e 3rd paragraph in
https://www.ietf.org/archive/id/draft-tls-reddy-slhdsa-00.html#section-2)
-Tiru
>
>
> Peter
>
>
>
> *From:* Russ Housley
> *Sent:* 03 November 2024 11:13
> *To:* tirumal reddy
> *Cc:* IETF TLS
> *Subject:* [TLS] Re: New Version Notification fo
Joe: Thanks for getting this posted.
TLS WG: This version address the comments we got (Rich was the only one). It is
ready to go to the AD.
spt
> On Nov 3, 2024, at 22:26, internet-dra...@ietf.org wrote:
>
> Internet-Draft draft-ietf-tls-rfc8447bis-10.txt is now available. It is a work
> item
Sent from my iPad
> On Oct 25, 2024, at 3:03 PM, Viktor Dukhovni wrote:
>
> On Fri, Oct 25, 2024 at 08:30:45AM -0400, Sean Turner wrote:
>
>> The TLS list is infamous in that it is regarded by some as [insert
>> your descriptive word; where the chairs have heard the following words
>> used: n
John Mattsson wrote:
> "Conversely, the fast version prioritizes speed over
> signature size, minimizing the time required to generate
> and verify signatures."
>
> This is incorrect. The "f" versions only have faster key
> generation and signing. They have slower verification.
Also:
"This docu
key generation and
signing. They have slower verification.
Cheers,
John
From: Peter C
Date: Sunday, 3 November 2024 at 17:49
To: tirumal reddy
Cc: IETF TLS
Subject: [TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt
Tiru,
Is SLH-DSA considered a practical option for TLS end-ent
it's being proposed for the full chain.
Peter
From: Russ Housley
Sent: 03 November 2024 11:13
To: tirumal reddy
Cc: IETF TLS
Subject: [TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt
Thanks for doing this work. I hope the TLS WG will promptly adopt it.
Russ
On Nov 2, 2
On Sun, Nov 03, 2024 at 12:49:59PM +, David Benjamin wrote:
> Hi all,
>
> So, Section 7 says the ACK contains:
> > A list of the records containing handshake messages in the current flight
> which the endpoint has received and either processed or buffered, in
> numerically increasing order.
>
Thanks for doing this work. I hope the TLS WG will promptly adopt it.
Russ
> On Nov 2, 2024, at 8:15 PM, tirumal reddy wrote:
>
> Hi all,
>
> This draft https://datatracker.ietf.org/doc/draft-tls-reddy-slhdsa/ specifies
> how the PQC signature scheme SLH-DSA can be used for authentication in
On Sun, Nov 03, 2024 at 05:37:34AM +0530, tirumal reddy wrote:
>
> The draft https://datatracker.ietf.org/doc/draft-tls-reddy-composite-mldsa/
> specifies how ML-DSA in combination with traditional algorithms can be used
> for authentication in TLS 1.3.
>
Important details, such as how signature
On Sun, Nov 03, 2024 at 05:45:13AM +0530, tirumal reddy wrote:
>
> This draft https://datatracker.ietf.org/doc/draft-tls-reddy-slhdsa/
> specifies how the PQC signature scheme SLH-DSA can be used for
> authentication in TLS 1.3.
I think the context to use should be taken as open question and
reso
On Sat, Nov 2, 2024 at 12:12 AM John Mattsson
wrote:
> Eric Rescorla wrote:
> >Is reuse of ML-KEM keys worse in some way than the reuse of ECDHE keys?
>
> No reuse of ephemeral keys is always bad.
>
Right.
Based on the discussion so far, I think it would be reasonable to have a
mandate for TLS
org
Subject: Re: [TLS] Re: MLKEM or Khyber KX
On Fri, Nov 1, 2024 at 11:30 AM John Mattsson
mailto:40ericsson@dmarc.ietf.org>>
wrote:
>and would warmly welcome it being a MUST in the IETF specification of the
ML-KEM TLS hybrids.
+1
Let’s try to make that happen
https://github.com/
On Fri, Nov 1, 2024 at 11:30 AM John Mattsson wrote:
> >and would warmly welcome it being a MUST in the IETF specification of
> the ML-KEM TLS hybrids.
>
>
> +1
>
> Let’s try to make that happen
>
> https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/pull/25
>
Is reus
Tangentially, this is registering a `NamedGroup` / `SupportedGroup`, but of
course it's not a group, it's a KEM scheme over which no Diffie-Hellman of any
kind can be done. Where do IANA preallocations start bumping up against "well
we're doing something completely different anyway"?
Your co-c
>and would warmly welcome it being a MUST in the IETF specification of the
ML-KEM TLS hybrids.
+1
Let’s try to make that happen
https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/pull/25
___
TLS mailing list -- tls@ietf.org
On Fri, Nov 1, 2024 at 2:02 PM Alicja Kario wrote:
> On Friday, 1 November 2024 18:02:44 CET, David Benjamin wrote:
> >> Tangentially, this is registering a `NamedGroup` /
> >> `SupportedGroup`, but of course it's not a group, it's a KEM
> >> scheme over which no Diffie-Hellman of any kind can b
On Friday, 1 November 2024 18:02:44 CET, David Benjamin wrote:
Tangentially, this is registering a `NamedGroup` /
`SupportedGroup`, but of course it's not a group, it's a KEM
scheme over which no Diffie-Hellman of any kind can be done.
Where do IANA preallocations start bumping up against "wel
We (Go) also generate fresh keys for each handshake and would warmly welcome it
being a MUST in the IETF specification of the ML-KEM TLS hybrids.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
> The FFDH range isn't treated special because of naming but because of
some mistakes that RFC 7919 made where the implementation actually needs to
categorize codepoints.
Gotcha, cheers.
I'm definitely not advocating another name change, it's not worth it
On Fri, Nov 1, 2024, 1:03 PM David Benja
> Tangentially, this is registering a `NamedGroup` / `SupportedGroup`, but
of course it's not a group, it's a KEM scheme over which no Diffie-Hellman
of any kind can be done. Where do IANA preallocations start bumping up
against "well we're doing something completely different anyway"?
The decidin
If there's a choice to be made I favor the 512 513 514 choices
On Fri, Nov 1, 2024, 12:20 PM Deirdre Connolly
wrote:
> Ah, oops!
>
> Tangentially, this is registering a `NamedGroup` / `SupportedGroup`, but
> of course it's not a group, it's a KEM scheme over which no Diffie-Hellman
> of any kind
Ah, oops!
Tangentially, this is registering a `NamedGroup` / `SupportedGroup`, but of
course it's not a group, it's a KEM scheme over which no Diffie-Hellman of
any kind can be done. Where do IANA preallocations start bumping up against
"well we're doing something completely different anyway"?
O
I made a mistake and you're right " 261, 262, and 263 are assigne to the
MLKEM512, MLKEM768, and MLKEM1024" wrong.
We'll notify IANA to pick 512 513 514 or 4584 4585 4586. Or something.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email
We are not planning on re-using MLKEM or Khyber keys for the key exchange.
Someone here is being obstinate, and I am looking for arguments to squelch him.
:)
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
On Fri, 1 Nov 2024 at 11:50, Bas Westerbaan wrote:
> Here we're not accounting for the new bottleneck on server upload which
> these post-quantum signatures add. But that's a bandwidth issue — not a
> compute one.
>
On top of that, the HRR/ClientHello Cookie extension already in TLS1.3 can
also
Bas Westerbaan
Date: Friday, 1 November 2024 at 13:33
To: Salz, Rich
Cc: tls@ietf.org
Subject: [TLS] Re: MLKEM or Khyber KX
BoringSSL (Chrome) generates a new keypair for each connection. We do too.
ML-KEM keygen is quite cheap anyway.
On Fri, Nov 1, 2024 at 1:11 PM Salz, Rich
mailto:40akam
BoringSSL (Chrome) generates a new keypair for each connection. We do too.
ML-KEM keygen is quite cheap anyway.
On Fri, Nov 1, 2024 at 1:11 PM Salz, Rich
wrote:
> Are folks generating a new key every connection or just using a
> longer-lived keypair and not re-using the random?
> ___
ers,
>
> John
>
>
>
> [1]
>
>
> https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/pqc-seminars/presentations/7-batch-me-if-you-pq-sign-07212023.pdf
>
>
>
> https://www.nist.gov/video/pqc-seminar-batch-me-if-you-pq-sign
>
>
>
>
&g
I fully agree.
In addition to that wide enough adoption of any mandatory changes to TLS
handshake will take years and any public facing services will have to allow
clients that do not support puzzles for backwards compatibility for quite
some time.
On top of low-powered battery operated clients t
vid Venhoek
Cc: tls@ietf.org
Subject: [TLS] Re: TLS client puzzles revival
I'm not very excited about this DoS approach. Many user-facing clients run on
battery-constrained devices, so burning CPU on a hash puzzle in those contexts
is unappealing. Before we resort to mitigating a server'
I'm not very excited about this DoS approach. Many user-facing clients run
on battery-constrained devices, so burning CPU on a hash puzzle in those
contexts is unappealing. Before we resort to mitigating a server's high
energy cost by increasing energy cost across the board, we should exhaust
avenu
=AOvVaw0ueyeUdjcs-FPnto51YIT8>
>
> --Ben Schwartz
> From: Benjamin Kaduk
> Sent: Monday, October 28, 2024 6:26 PM
> To: Ben Schwartz
> Cc: Lucas Pardue ;
> draft-ietf-tls-svcb-ech@ietf.org ;
> tls@ietf.org
> Subject: Re: [TLS] Re: Genart last call review of draf
-ietf-tls-svcb-ech@ietf.org
; tls@ietf.org
Subject: Re: [TLS] Re: Genart last call review of draft-ietf-tls-svcb-ech-06
On Mon, Oct 28, 2024 at 09:37:27PM +, Ben Schwartz wrote:
>This Message Is From an External Sender
>This message came from outside your organization.
>
Hi,
I support the adoption of this document.
Best,
/Marco
On 2024-10-25 04:46, Sean Turner wrote:
At the TLS meeting at IETF 119 we discussed the Large Record Sizes for TLS and
DTLS I-D; see [0] and [1]. There has been some list discussion; see [2] and
[3]. The I-D has been revised a few tim
I support the adoption of the draft
On Fri, Oct 25, 2024 at 4:48 AM Sean Turner wrote:
>
> At the TLS meeting at IETF 119 we discussed the Large Record Sizes for TLS
> and DTLS I-D; see [0] and [1]. There has been some list discussion; see [2]
> and [3]. The I-D has been revised a few times sin
Hi,
I support adoption of this draft.
Regards,
Valery.
> Just a reminder that this adoption call is still on going.
>
> spt
>
> > On Oct 24, 2024, at 22:46, Sean Turner wrote:
> >
> > At the TLS meeting at IETF 119 we discussed the Large Record Sizes for TLS
> and DTLS I-D; see [0] and [1]. T
> Just a reminder that this adoption call is still on going.
I support adoption.
One place I think we would use it is for links among datacenters that connect
our own software. (Excuse the clumsy wording, I can never tell inter- and
intra- apart)
__
On Thu, Oct 24, 2024 at 12:39:28PM +0100, Stephen Farrell wrote:
>
>
> On 23/10/2024 18:29, Bas Westerbaan wrote:
> >
> > Unless I overlooked something, we don't have a draft out to assign a
> > SignatureAlgorithm to ML-DSA for use in TLS.
Nitpick: SignatureScheme. :-)
(SignatureAlgorithm is f
I support adoption of the draft, it is useful in telco networks.
-Tiru
On Fri, 25 Oct 2024 at 08:18, Sean Turner wrote:
> At the TLS meeting at IETF 119 we discussed the Large Record Sizes for TLS
> and DTLS I-D; see [0] and [1]. There has been some list discussion; see [2]
> and [3]. The I-D h
Just a reminder that this adoption call is still on going.
spt
> On Oct 24, 2024, at 22:46, Sean Turner wrote:
>
> At the TLS meeting at IETF 119 we discussed the Large Record Sizes for TLS
> and DTLS I-D; see [0] and [1]. There has been some list discussion; see [2]
> and [3]. The I-D has be
Thanks Rich. These all look good to me.
spt
> On Oct 16, 2024, at 15:23, Salz, Rich
> wrote:
>
> This email starts the working group last call for "IANA Registry Updates for
> TLS and DTLS” I-D, located here:
>
> I found a few nits. Diff at https://github.com/tlswg/rfc8447bis/pull/58/files
On Mon, Oct 28, 2024 at 09:37:27PM +, Ben Schwartz wrote:
>This Message Is From an External Sender
>This message came from outside your organization.
>
>On ALPNs - Yes, this is something of an open question. There are some
>hints about this in draft-ietf-tls-esni, e.g. Sec
Hey Ben,
Responding in line:
On Mon, Oct 28, 2024, at 21:37, Ben Schwartz wrote:
> On ALPNs - Yes, this is something of an open question. There are some hints
> about this in draft-ietf-tls-esni, e.g. Section 10.5: "A client that treats
> this context as sensitive SHOULD NOT send context-speci
On ALPNs - Yes, this is something of an open question. There are some hints
about this in draft-ietf-tls-esni, e.g. Section 10.5: "A client that treats
this context as sensitive SHOULD NOT send context-specific values in
ClientHelloOuter.".
I've occasionally wondered if we would define an ECHC
> On Oct 25, 2024, at 10:52, Salz, Rich wrote:
>
> I mean "IANA cannot have designated..."
>
> I blame auto-correct. Or outlook. Anyone other than me.
>
> On 10/25/24, 10:50 AM, "Salz, Rich" wrote:
>
>> The following PR creates the TLS Flags sub-registry where we can manage the
>> actua
1 - 100 of 900 matches
Mail list logo
