On Sat, Apr 1, 2023 at 12:15 PM Dmitry Belyavsky wrote:
> Dear Martin,
>
> On Sat, 1 Apr 2023, 19:36 Martin Thomson, wrote:
>
>> On Sat, Apr 1, 2023, at 20:28, Dmitry Belyavsky wrote:
>> > Are the things like national-wide standards considered as new features
>> > (until they don't pretend to be
Dear Martin,
On Sat, 1 Apr 2023, 19:36 Martin Thomson, wrote:
> On Sat, Apr 1, 2023, at 20:28, Dmitry Belyavsky wrote:
> > Are the things like national-wide standards considered as new features
> > (until they don't pretend to be Internet-wide standards)?
>
> I would not expect the IETF to be sp
On Sat, Apr 1, 2023, at 20:28, Dmitry Belyavsky wrote:
> Are the things like national-wide standards considered as new features
> (until they don't pretend to be Internet-wide standards)?
I would not expect the IETF to be specifying national standards (that's an
obvious contradiction anyway).
It
Dear Rich,
Are the things like national-wide standards considered as new features
(until they don't pretend to be Internet-wide standards)?
On Fri, Mar 31, 2023 at 2:11 AM Salz, Rich
wrote:
>
> FWIW, my plan for the draft (which I hope to submit for adoption within a
> month) is to include text
FWIW, my plan for the draft (which I hope to submit for adoption within a
month) is to include text that says, basically, while no new features will be
ADDED to TLS 1.2, the WG may decide to deprecate or remove things that have
become security risks. I think it's better to keep specifics in sep
On Thu, Mar 30, 2023 at 3:58 PM David Benjamin
wrote:
> post_handshake_auth was only in TLS 1.3 because some folks relied on an
> existing (and terrible :-) ) corresponding mechanism in TLS 1.2: trigger a
> renegotiation and request a client certificate in the new handshake. I
> don't think it ma
post_handshake_auth was only in TLS 1.3 because some folks relied on an
existing (and terrible :-) ) corresponding mechanism in TLS 1.2: trigger a
renegotiation and request a client certificate in the new handshake. I
don't think it makes sense to backport post_handshake_auth to TLS 1.2. Such
a bac
Hi,
What I noticed is that something close to "post_handshake_auth" has been
asked for in TLS 1.2.
If you go look at the registry, which of course some people here know well,
there are a bunch of them that are only defined for TLS 1.3.
https://www.iana.org/assignments/tls-extensiontype-values/tl
It was good. The only thing I would add is that I think client authentication
is already much different in 1.3, and that new extensions such as ECH are
already not being done for 1.2.
Do you think discussion of client auth should be described in the draft?
Yes, new work is not being done for 1.
