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.
Joe
___
TLS mailing l
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 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
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 suggested that another way to “fix” TLS was to specify a version
o
> 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
I've updated draft-connolly-tls-mlkem-key-agreement to include the updated
IANA codepoints (they were initially allocated in the reserved FFDH section)
https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/
-- Forwarded message -
From:
Date: Tue, Nov 5, 2024 at
The TLS WG has placed draft-gutmann-tls-lts in state
Call For Adoption By WG Issued (entered by Sean Turner)
The document is available at
https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/
___
TLS mailing list -- tls@ietf.org
To unsubscribe send
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
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 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 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 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 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 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 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
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 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
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
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
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
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
22 matches
Mail list logo
