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,
Jo
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
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
>
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
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 p
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 overcom
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
via
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 so
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 sui
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
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
environmen
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 as
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 trailin
* I think the term telecom is as obsolete as TLS 1.2 :)
Touche’ :)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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".
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 an
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
17 matches
Mail list logo
