On Tue, Jan 2, 2024 at 8:31 PM Eric Rescorla wrote:
>
>
> On Tue, Jan 2, 2024 at 8:17 PM Benjamin Kaduk 40akamai@dmarc.ietf.org> wrote:
>
>> On Tue, Jan 02, 2024 at 07:17:44PM -0800, Eric Rescorla wrote:
>> >
>> >The issue I am concerned about is that:
>> >1. Implementors who do not
>On Wed, Jan 3, 2024, at 15:30, Eric Rescorla wrote:
>> In the interest of clarity, I favor the WG declining to work on
>> extending TLS 1.2, so these cipher suites should be marked as
>> Recommended=No. I'm just concerned that closing the registries entirely
>> will not have the best results.
>
On Wed, Jan 3, 2024, at 15:30, Eric Rescorla wrote:
> In the interest of clarity, I favor the WG declining to work on
> extending TLS 1.2, so these cipher suites should be marked as
> Recommended=No. I'm just concerned that closing the registries entirely
> will not have the best results.
This
On Tue, Jan 2, 2024 at 8:17 PM Benjamin Kaduk wrote:
> On Tue, Jan 02, 2024 at 07:17:44PM -0800, Eric Rescorla wrote:
> >On Tue, Jan 2, 2024 at 5:02 PM Rob Sayre <[1]say...@gmail.com> wrote:
> >
> > It might be better to describe TLS 1.2 as "overtaken by events". If
> you
> > want t
On Tue, Jan 02, 2024 at 07:17:44PM -0800, Eric Rescorla wrote:
>On Tue, Jan 2, 2024 at 5:02 PM Rob Sayre <[1]say...@gmail.com> wrote:
>
> It might be better to describe TLS 1.2 as "overtaken by events". If you
> want to use CSS Grid or Swift UI (name any newish thing), you'll find
>
On Tue, Jan 2, 2024 at 5:02 PM Rob Sayre wrote:
> It might be better to describe TLS 1.2 as "overtaken by events". If you
> want to use CSS Grid or Swift UI (name any newish thing), you'll find
> yourself with a stack that supports TLS 1.3, so there's no need to bother
> with TLS 1.2 in those cas
Salz, Rich writes:
> My starting assumption here is that the majority of people implementing
> TLS and/or deciding what to authorize for deployment TLS-wise, are not
> stupid, and understand the benefits of the newer protocol version,
> including its added security. And capable of evaluat
.
- C. A. R. Hoare
From: TLS on behalf of Rob Sayre
Date: Tuesday, January 2, 2024 at 20:03
To: Martin Thomson
Cc: "TLS@ietf.org"
Subject: Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freez
It might be better to describe TLS 1.2 as "overtaken by events". If you
want to use CSS Grid or Swift UI (name any newish thing), you'll find
yourself with a stack that supports TLS 1.3, so there's no need to bother
with TLS 1.2 in those cases. Turning off TLS 1.2 is sometimes a good idea,
because
On Wed, Jan 3, 2024, at 01:20, Salz, Rich wrote:
> That is not what the just-adopted draft says. It says that except for
> ALPN and exporters that no new registrations will be accepted for TLS
> 1.2 and that new entries should have a Note comment that says “for TLS
> 1.3 or later”. This is a ch
important that we get it
right …
And I don’t think we did.
TNX
From: TLS On Behalf Of Salz, Rich
Sent: Tuesday, January 2, 2024 10:06 AM
To: Blumenthal, Uri - 0553 - MITLL
Cc: TLS@ietf.org
Subject: Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
My starting
right …
-Tim
From: TLS On Behalf Of Salz, Rich
Sent: Tuesday, January 2, 2024 10:06 AM
To: Blumenthal, Uri - 0553 - MITLL
Cc: TLS@ietf.org
Subject: Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
My starting assumption here is that the majority of people implem
I agree that IANA registrations aren't a great place to constrain this.
First, constraining the registry for TLS 1.2 and not DTLS 1.2 makes a lot
of things very weird. For a feature that's TLS/DTLS-agnostic, like
post-quantum, it helps no one to define it for DTLS 1.2 and not TLS 1.2.
Most of the
On Tue, Jan 2, 2024 at 6:20 AM Salz, Rich wrote:
> I'm not Martin, but I believe that his point is that both TLS ciphersuites
> and TLS supported groups/EC curves permit registration outside of the IETF
> process based on the existence of.a specification. As long as PQC can fit
> into new ciphers
My starting assumption here is that the majority of people implementing TLS
and/or deciding what to authorize for deployment TLS-wise, are not stupid, and
understand the benefits of the newer protocol version, including its added
security. And capable of evaluating the risks of moving to TLS 1.3
>jQcmQRYFpfptBannerEnd
>> Those who can move to 1.3+, will do so, regardless of this draft. Those who
>>can’t, would
>> do whatever’s appropriate in their case – again, regardless of this draft.
>
> Same as for any other IETF document. :)
:-)
Yes, but not quite – as other IETF docum
On Tue, Jan 2, 2024 at 3:30 PM Salz, Rich
wrote:
> Those who can move to 1.3+, will do so, regardless of this draft. Those
> who can’t, would do whatever’s appropriate in their case – again,
> regardless of this draft.
>
>
>
> Same as for any other IETF document. :)
>
>
>
> One difference in the
Those who can move to 1.3+, will do so, regardless of this draft. Those who
can’t, would do whatever’s appropriate in their case – again, regardless of
this draft.
Same as for any other IETF document. :)
One difference in the current wording is that it would become trivially more
difficult to
>> I'm not Martin, but I believe that his point is that both TLS ciphersuites
>>and TLS supported groups/EC curves
>> permit registration outside of the IETF process based on the existence of.a
>> specification. As long as PQC can
>> fit into new ciphersuites and group types, then anyone can
I'm not Martin, but I believe that his point is that both TLS ciphersuites and
TLS supported groups/EC curves permit registration outside of the IETF process
based on the existence of.a specification. As long as PQC can fit into new
ciphersuites and group types, then anyone can specify it for TL
On Mon, Jan 1, 2024 at 7:05 PM Rob Sayre wrote:
> Martin,
>
> You haven’t formed a complete sentence here. That’s usually allowable, but
> not in this instance.
>
> Uri said there might be “special cases”. Anyone can make TLS 1.2 PQ, it
> just won’t be called TLS.
>
I'm not Martin, but I believe
Martin,
You haven’t formed a complete sentence here. That’s usually allowable, but
not in this instance.
Uri said there might be “special cases”. Anyone can make TLS 1.2 PQ, it
just won’t be called TLS.
thanks,
Rob
On Mon, Jan 1, 2024 at 17:56 Martin Thomson wrote:
>
>
> On Fri, Dec 22, 2023,
On Fri, Dec 22, 2023, at 10:23, Salz, Rich wrote:
> Of course. We’re not the protocol police and nobody from the IETF will
> come and arrest anyone who uses Kyber-based key exchange in TLS 1.2 But
> with this document, they will not be able to register such an algorithm
> for 1.2
I don’t thi
You can tell the reader whatever you want. The fact remains that if the only
way to add QR to the currently deployed TLS-1.2-based “stuff” is modifying
TLS-1.2, then that’s what will be done in that particular case.
Of course. We’re not the protocol police and nobody from the IETF will come
an
-1 to Tim.
You can tell the reader whatever you want. The fact remains that if the only
way to add QR to the currently deployed TLS-1.2-based “stuff” is modifying
TLS-1.2, then that’s what will be done in that particular case.
I hope that the majority of the installed base would be abl
25 matches
Mail list logo
