The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Bootstrapping TLS Encrypted ClientHello
with DNS Service Bindings'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this
On Thu, 20 Feb 2025 at 10:13, Bellebaum, Thomas <
thomas.belleb...@aisec.fraunhofer.de> wrote:
> > A TLS application interacting with an end-user (e.g. a browser) MUST
> clearly communicate any requests to log TLS secrets to the user and MUST
> NOT indicate a secure connection.
>
The connection i
Hello,
I have just become aware of this draft and I believe there might be a good
cautionary addition I would like to propose:
Specifically, I am worried that with further encouragement to standardize this
format, it will become a convenient way to surveil unsuspecting end users. All
this requ
Hi all,
The revised https://datatracker.ietf.org/doc/draft-reddy-uta-pqc-app/
addresses comments from the WG. It discusses Quantum-Ready usage profiles
for TLS-based Applications to defend against passive and on-path attacks
employing CRQCs.
Further comments and suggestions are welcome.
Best Reg
The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'TLS Encrypted Client Hello'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive commen
> I think we should abandon this effort and not publish.
>
> When initially proposed this was supposed to be documenting a
> deployed reality. I could just about hold my nose with that,
> but adding in ECH (for which key exfiltration is not currently
> deployed, nor seemingly needed) and the IANA
On Thursday, 20 February 2025 13:12:48 CET, Bellebaum, Thomas wrote:
The connection is secure. TLS doesn't defend against compromised devices.
I disagree. While the *network* connection itself may inhibit
the rather technical notions of confidentiality and integrity,
this is not what the aver
On 20/02/2025 12:36, Alicja Kario wrote:
sorry, but the threat model you're talking about is not realistic
I disagree.
While it may not be feasible to notify a user, the threat of
widely deployed software that supports key exfiltration being
abused is real, and made worse by us standardising
> While it may not be feasible to notify a user, the threat of
> widely deployed software that supports key exfiltration being
> abused is real, and made worse by us standardising on this
> way of documenting what is to be exfiltrated.
There already is widely deployed software that leaks key infor
Hey,
I disagree with this because if an attacker could write to the environment
variable used by the program or is able to side-load a library and capture
outbound packets, it is very likely that they already have privileged
access to the machine.
However, I acknowledge that allowing an attacker
Standard file formats seem fine, non?
On Thu, 20 Feb 2025, 21:20 _ _, wrote:
> Hey,
>
> I disagree with this because if an attacker could write to the environment
> variable used by the program or is able to side-load a library and capture
> outbound packets, it is very likely that they already
> The connection is secure. TLS doesn't defend against compromised devices.
I disagree. While the *network* connection itself may inhibit the rather
technical notions of confidentiality and integrity, this is not what the
average user would consider a "secure connection". Staying with a browser
12 matches
Mail list logo
