I support eventual publication of this (see last paragraph), but the IANA
considerations (Section 6) does not belong. First, it is the wrong level of
review, as Stephen has pointed out; that alone is enough to send the draft back
to the WG. Even if that is fixed, the instructions to the DE’s ar
Issues
--
* tlswg/draft-ietf-tls-cert-abridge (+0/-0/💬1)
1 issues received 1 new comments:
- #16 Longterm versioning strategy (1 by ilaril)
https://github.com/tlswg/draft-ietf-tls-cert-abridge/issues/16
Repositories tracked by this digest:
---
* ht
Hi all,
* I don't think there is much ECH spec can do about this - versatility of
public name construction depends on many internal operational details of the
hosting service.
Don’t agree. It is possible. Just introduce 2 stages for adoption:
1. Stage 1: TLS extension that makes
Watson Ladd writes:
> Authentication is not like encryption.
I presume that you're alluding to the following process: if the PQ
signature system is broken, we revert to ECC signatures, and then the
attacker doesn't benefit from forging the no-longer-accepted signatures
(whereas we can't stop attac
+1
-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
Sent: Friday, November 15, 2024 11:41 AM
To: Bas Westerbaan ; tls@ietf.org
Subject: [TLS] Re: ML-DSA in TLS
On 15/11/2024 10:51, Bas Westerbaan wrote:
> We have posted a -00.
>
> https://datatracker.ietf.or
The following errata report has been submitted for RFC8422,
"Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security
(TLS) Versions 1.2 and Earlier".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid8179
