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 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,
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
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
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
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 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
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
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
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
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
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
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
> 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
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
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
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
17 matches
Mail list logo
