Hi all,
We recently published draft-ietf-tls-trust-anchor-ids-00:
URL:
https://www.ietf.org/archive/id/draft-ietf-tls-trust-anchor-ids-00.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-tls-trust-anchor-ids/
HTML:
https://www.ietf.org/archive/id/draft-ietf-tls-trust-anchor-ids-00.html
HT
Thank you for posting the additional information. I reviewed it. (And as a
member of LAMPS I lived it as well :)
I (still) support adoption.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
Hiya,
On 28/02/2025 18:56, Sean Turner wrote:
In response to the WG adoption call, Dan Bernstein pointed out some
potential IPR (see [0]), but no IPR disclosure has been made in
accordance with BCP 79.
While I don't think the lack of an IPR declaration is fatal
here, I do think it'd be great
Sean Turner writes:
> BCP 79 makes this important point:
> (b) The IETF, following normal processes, can decide to use
> technology for which IPR disclosures have been made if it decides
> that such a use is warranted.
https://cr.yp.to/2025/bcp-79-issues.html covers that argument (giving
In response to the WG adoption call, Dan Bernstein pointed out some potential
IPR (see [0]), but no IPR disclosure has been made in accordance with BCP 79.
Additional information is provided here; see [1].
BCP 79 makes this important point:
(b) The IETF, following normal processes, can decid
Fascinating thread.
I propose *NoSecurity* mode. Debug mode, with an insecurity label.
Perhaps defining SSLKEYLOGFILE only in debug mode is tolerable.
On Thu, 20 Feb 2025, 11:28 Ben Smyth, wrote:
> On Thu, 20 Feb 2025 at 10:13, Bellebaum, Thomas <
> thomas.belleb...@aisec.fraunhofer.de> wrote:
Hi Ilari,
At 12:18 AM 28-02-2025, Ilari Liusvaara wrote:
What kind of private keys? Is that just the known trouble (TLS_RSA_*,
TLS_PSK_* and the session ticket extension), or is it also other key
types? Of those, only the pure-PSK stuff remains in TLS 1.3 (TLS 1.3
does have session tickets, but t
On Thu, Feb 27, 2025 at 12:59:56PM -0800, S Moonesamy wrote:
> Hi Brian, Stephen,
> At 06:18 AM 27-02-2025, Stephen Farrell wrote:
> > From my POV yes: fundamentally it is a bad idea for
> > the IETF to standardise ways to exfiltrate keys
> > even if there may be innocuous uses for those. And
> > t
Hi,
Isn't this off-topic? The IETF can't stop you from having a meeting, but
you're crossing the line by using IETF lists to advertise it.
thanks,
Rob
On Thu, Feb 27, 2025 at 11:08 PM John Mattsson wrote:
> Hi,
>
>
>
> There was significant interest from several countries to have a
> side-mee
ECDHE only helps if the connections are short-lived, otherwise
CLIENT/SERVER_TRAFFIC_SECRET_0 is enough for passively eavesdropping on the
whole connection. Connections lasting months or even years are not uncommon. It
is essential to frequently rekey using asymmetric ephemeral key exchange
(ED
Without weighing in on the rest of this debate, I don't think that
"SSLKEYLOGFILE" and it's associated registry should become a generic
carrier for keying material for other protocols. It's not like this is a
complicated format. If those protocols wish to define some expert (assuming
ad arguendo th
Internet-Draft draft-jhoyla-req-mtls-flag-02.txt is now available. It is a
work item of the Transport Layer Security (TLS) WG of the IETF.
Title: TLS Flag - Request mTLS
Author: Jonathan Hoyland
Name:draft-jhoyla-req-mtls-flag-02.txt
Pages: 4
Dates: 2025-02-28
Abstract:
Hi,
There was significant interest from several countries to have a side-meeting on
PQC at IETF 122 Bangkok, so Ericsson will organize such a meeting on Monday 17
March 15.15 - 16.45 Bangkok time in Meeting Room 2 [40 seats] (overlapping with
Monday Session III). It is possible to attend remote
Just a remind to send in those agenda requests.
spt
> On Feb 19, 2025, at 9:16 AM, Sean Turner wrote:
>
> The TLS WG requested a two hour session and a one hour session at IETF 122
> [0]; the draft agenda has us on Tuesday and Thursday. For planning purposes,
> the chairs would like to solici
On 28/02/2025 10:47, John Mattsson wrote:
I think it is an interesting idea to use the KEYLOG format to help
debugging of other security protocols. I think easy debugging helps
deployment of security protocols.
I think each protocol should have its own registry. The registries
could be listed
I think it is an interesting idea to use the KEYLOG format to help debugging of
other security protocols. I think easy debugging helps deployment of security
protocols.
I think each protocol should have its own registry. The registries could be
listed under the same IANS KEYLOGFILE name space.
> Step0: we have this existing deployed thing we want to document.
As I wrote in [1], republishing without adding considerations and guard rails
is already bad.
> I think it is an interesting idea to use the KEYLOG format to help
> debugging of other security protocols. I think easy debugging he
17 matches
Mail list logo
