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
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
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
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
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
* 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
+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
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/
__
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.
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
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,
>
>
+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:
> >
12 matches
Mail list logo
