+1
Arnaud Taddei
Global Security Strategist | Enterprise Security Group | ITU-T SG17 chair
mobile: +41 79 506 1129
Geneva, Switzerland
arnaud.tad...@broadcom.com | broadcom.com
On Mon, Feb 24, 2025 at 10:55 PM Martin Thomson wrote:
> On Tue, Feb 25, 2025, at 06:56, Aaron Zauner wrote:
> >
sorry, open source != standardisation and vice versa
Arnaud Taddei
Global Security Strategist | Enterprise Security Group | ITU-T SG17 chair
mobile: +41 79 506 1129
Geneva, Switzerland
arnaud.tad...@broadcom.com | broadcom.com
On Mon, Feb 24, 2025 at 11:30 PM Aaron Zauner wrote:
> Hey,
>
>
Hi! The chairs gathered a lot of information from this thread. Thanks for that.
We have also noted PQ-related discussions in other WGs. Based on all of this,
Joe and I [0] are going to begin to issue WG calls for adoption in this order
one roughly right after the after:
- draft-kwiatkowski-tl
Hi everyone,
I’ve put together a draft, “Implicit ECH Configuration for TLS 1.3” (
https://www.ietf.org/archive/id/draft-sullivan-tls-implicit-ech-00.html),
as a potential starting point for improving ECH’s “do not stick out”
compliance. Global deployments of ECH have become biased because a singl
I approve.
The draft does not say if the existing TLS DE's will do the new table, but I am
okay with taking on that additional workload :)
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
Internet-Draft draft-ietf-tls-trust-anchor-ids-00.txt is now available. It is
a work item of the Transport Layer Security (TLS) WG of the IETF.
Title: TLS Trust Anchor Identifiers
Authors: Bob Beck
David Benjamin
Devon O'Brien
Kyle Nekritz
Name:dr
* But I don't know of anywhere else with broad enough remit
* to mandate a behavior for all applications using TLS.
This is a common perception, and it is exactly why publishing SSLKEYLOGFILE
documents in the context of the IETF is a bad idea. This creates additional
pressure on other imp
Dear Yoav Nir, Rich Salz (cc: tls WG, tls-reg-review mailing list, Nick
Sullivan),
As the designated experts for the TLS ExtensionType Values registry, can you
review the proposed registration in draft-ietf-tls-esni-23 for us? Please note
that Nick Sullivan is a co-author for this draft.
Plea
All,
I fully support standardizing the SSLKEYLOGFILE Format.
While it is a debugging tool, that doesn’t mean it doesn’t have to be
standardized.
Where I work we maintain a large set of protocol analysis tools
used to verify correct operation of various programs, and document variant
behaviors.
I fully agree with Martin. IETF has historically not been just about bits on
the wire. I am sanguine that this creates new security concerns that are not
already present[1]
[1] https://mailarchive.ietf.org/arch/msg/tls/ySWMlQieatYXs6J-3YSHtvhSYCM/
__
Hiya,
On 24/02/2025 21:54, Martin Thomson wrote:
but
this is a case where that interoperation already exists.
I think the above was true of your initial draft Martin,
but is significantly less true of the current draft that
includes an IANA registry setup with the specification
required proced
+1
Arnaud Taddei
Global Security Strategist | Enterprise Security Group | ITU-T SG17 chair
mobile: +41 79 506 1129
Geneva, Switzerland
arnaud.tad...@broadcom.com | broadcom.com
On Tue, Feb 25, 2025 at 3:38 PM Salz, Rich wrote:
> I fully agree with Martin. IETF has historically not been ju
12 matches
Mail list logo
