2021-11-04 11:12 GMT-04:00 David Benjamin :
> Indeed it's *because* there is still an existing 1.2 deployment that we
> should be judicious with backports. Today, nearly every TLS implementation
> needs to implement both 1.2 and 1.3. The ClientHello is cross-version, so it
> is not possible for
FWIW, while I don't think we should be doing much enhancement of (D)TLS
1.2, I also don't think it makes sense not to allow enhancements to 1.3 to
be used with 1.2 where that makes sense, as it seems to here.
-Ekr
On Thu, Nov 4, 2021 at 11:05 AM Achim Kraus wrote:
> Hi Sean,
>
> I hope, the
Hi Sean,
I hope, the answer of Hannes counts as "significant justification".
Most of the discussion and arguments are about TLS 1.2 and 1.3.
Just to be clear:
RRC will only apply to DTLS, 1.2 and 1.3. There is no usage for TLS.
And for RRC, Hannes and Thomas wants to use the "Flags Extension".
Hi David,
* While it's true there is still plenty of 1.2 in many environments,
defining a new extension like flags or connection ID won't make it apply to
those connections. Both sides need to deploy new code to implement that
extension. That means we shouldn't be looking at the
I think the term telecom is as obsolete as TLS 1.2 :) Mobile network are all
IP, and voice communication is to a large degree provided by Internet
companies. 3GPP operates in generations every 10 years (2G, 3G, 4G, 5G, 6G),
half generations every 5 years (GPRS, HSPA, 4G LTE Advanced), as well
While it's true there is still plenty of 1.2 in many environments, defining
a new extension like flags or connection ID won't make it apply to those
connections. Both sides need to deploy new code to implement that
extension. That means we shouldn't be looking at the trailing end of each
I am amused to see a telecom person saying obsolete when it’s only 2-3 years
old. In my discussions I’ve found that they think in terms of at least 10
years. ☺
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
The term "obsolete" appears to be used incorrectly when it comes to TLS/DTLS
1.2 used in the IoT environment. It is widely used today and I expect it to be
used for a while since (a) there are no security problems with it (when
configured correctly), and (b) for many use cases it also offers
The problem we ran into is the following: We are just publishing the RFCs for
the connection IDs for DTLS 1.2 and for DTLS 1.3. For the RRC work we need to
define an extension. Using the flags extension makes a lot of sense for TLS 1.3
(to avoid wasting bytes sent over the wire). Should we do
Hannes,
Sorry I forgot to answer this, but John pretty much answered it for me. The
prevailing notion that the WG has been under is that extensions defined are for
TLS 1.3. We put the following in the charter to make that clear:
Changes or additions to older versions of (D)TLS whether
Hi,
I think this is a great document with a lot of good information.
I think some things that should be more positive:
-- For both PSK authentication and PSK key exchange without (EC)DHE the bad
security properties such as lack of identity protection and lack of forward
secrecy can be
Martin,
Paul Grubbs approached us about presenting some work he has done to show "how
zero-knowledge proofs can be used to prove properties of TLS plaintexts, and
describes how this can solve problems related to TLS ‘visibility' in a
privacy-preserving way, with no changes needed to TLS. His
TLS 1.2 has been obsolete for over three years. Oxford dictionary defines
obsolete as "no longer produced or used; out of date." NIST requires support of
TLS 1.3 everywhere no later than Jan 2024, which at least in theory means no
negotiation of TLS 1.2.
I think IETF, TLS WG, and TLS libraries
As a quick update, we're still in the process of reviewing the proposed change.
Time pending, we may throw it on the agenda for next week's meeting.
Best,
Chris
On Thu, Oct 14, 2021, at 3:53 PM, Christopher Wood wrote:
> The PR's been updated to correct the editorial bug and clarify that the
>
Thanks, Martin! I agree with your point about the external PSK. I filed this
issue to track its resolution:
https://github.com/tlswg/external-psk-design-team/issues/76
I'll discuss the larger redundancy concern with the authors and see if there
are some quick fixes to be made.
Best,
Chris
I think the best way to think about AEAD from a protocol standpoint is as an
interface. This is especially true for TLS where there are algorithms like
TLS_SHA256_SHA256 for the AEAD interface that do not do encryption. A TLS
cipher suite either use the AEAD interface or it does not.
Cheers,
alex.sch...@gmx.de writes:
>I would really appreciate a response to get some clarification on what the
>intended interpretation is, i.e., when the extension should be used.
There's not really any contradiction, encrypt-then-MAC has nothing to do with
AEAD which is an all-in-one mode, so it
Hey Sean, what is "Zero-Knowledge Proofs meet TLS"? I can't find a draft and
the link in the agenda is busted.
On Wed, Oct 20, 2021, at 06:46, Sean Turner wrote:
> Hi! We have a meeting time scheduled for Tuesday, 9 November 2021 from
> 1600-1800 (UTC). Please send in your agenda topics along
18 matches
Mail list logo
