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
>> 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
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
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
>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
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
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
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
Most people in the positions you describe are not experts themselves, but rely
on the recommendations and analysis of prominent industry groups because they
know that that is likely to produce better answers than every IT practitioner
trying to determine the answer themselves.
The best and b
Most people in the positions you describe are not experts themselves, but rely
on the recommendations and analysis of prominent industry groups because they
know that that is likely to produce better answers than every IT practitioner
trying to determine the answer themselves.
Agree, in gene
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
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
This draft will likely be ignored, except by the Web browser crowd, Swift UI,
and such ilk.
One problem with this draft is that such “fanatical/extremist” documents
diminish credibility of the body that sanctioned them in the eyes of those who
deal with “real” equipment (again, excluding st
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
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
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 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 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 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 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
20 matches
Mail list logo
