[TLS] Re: I-D Action: draft-denis-tls-aegis-03.txt

[John Mattsson]

Hi,

Looking at the performance figures for the X2 and X4 variant of AEGIS on AMD 
Zen 4 and Apple M1, I started thinking if adding parallelism at the algorithm 
level is the right solution. An alternative is to add parallelism at the 
protocol level similar to IPsec, something DTLS 1.3 and QUIC do not currently 
support. In QUIC and DTLS 1.3 you could for example add an extension to include 
the Connection ID in the derivation of traffic secrets (lets ignore key updates 
for now) and use several Connection IDs in parallel over a single connection.

Would 2 or 4 parallel AEGIS-128L have better performance than AEGIS-128X2 and 
AEGIS-128X4?

https://github.com/jedisct1/aegis-X

Cheers,
John

On 2024-12-01, 14:23, "internet-dra...@ietf.org"  
wrote:
Internet-Draft draft-denis-tls-aegis-03.txt is now available.

   Title:   AEGIS-based Cipher Suites for TLS 1.3, DTLS 1.3 and QUIC
   Authors: Frank Denis
Samuel Lucas
   Name:draft-denis-tls-aegis-03.txt
   Pages:   9
   Dates:   2024-12-01

Abstract:

   This document proposes new cipher suites based on the AEGIS family of
   authenticated encryption algorithms for integration into the TLS 1.3,
   DTLS 1.3, and QUIC protocols.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-denis-tls-aegis/.

   Source for this draft and an issue tracker can be found at
   https://github.com/jedisct1/draft-denis-tls-aegis.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-denis-tls-aegis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-denis-tls-aegis-03.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-denis-tls-aegis-03

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts



___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze

[Alicja Kario]

I think it's ready for publication.

On Tuesday, 3 December 2024 22:26:30 CET, Sean Turner wrote:
This is the working group last call for TLS 1.2 is in Feature 
Freeze. Please review draft-ietf-tls-tls12-frozen [1] and reply 
to this thread indicating if you think it is ready for 
publication or not.  If you do not think it is ready please 
indicate why.  This call will end on December 17, 2024.


Cheers,
spt

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/


--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

[Alicja Kario]

On Saturday, 7 December 2024 23:32:03 CET, D. J. Bernstein wrote:

Watson Ladd writes:

Having MLKEM without a hybrid as an option in TLS when the interoperable
choice is a hybrid


Some previous messages claim that there's a split between customers
demanding hybrids and customers demanding non-hybrids so "we'll end up
standardizing both". If the claim is true (I'm skeptical about the
non-hybrid part) and IETF acts on it (which is what I'm objecting to),
then how exactly does a hybrid end up as "the interoperable choice"?


same way that when DOD CAC was using DSA, long after no commercial CA was
using DSA, the public Internet servers that would accept those CAC's were
perfectly happy using RSA server keys so that regular browsers were
able to connect to them, even without use of a CAC

If no browser will implement pure ML-KEM (and it very much looks so), then
they will have to provide support for secp256r1MLKEM768 group to allow
connections from regular browsers: hybrids will be the interoperable choice
--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

[Alicja Kario]

+1 for adoption

While I'm stronly against wide deployment of pure ML-KEM at this moment in
time, I'm very much in favour of adoption of this document, having
stable definitions for such codepoints, even if they will get doployed only
in closed networks is still useful.

On Thursday, 5 December 2024 22:08:45 CET, Scott Fluhrer (sfluhrer) wrote:

How do we proceed with this draft?
 
This draft is quite boring (which is good from a 
cryptographical perspective); it just says ‘take ML-KEM and 
insert it as a key agreement into TLS in the obvious way’.
 
I understand that people want to discuss the hybrid KEM draft 
more (because there are more options there) – can we at least 
get the less controversial part done?


--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] I-D Action: draft-ietf-tls-tls12-frozen-03.txt

[internet-drafts]

Internet-Draft draft-ietf-tls-tls12-frozen-03.txt is now available. It is a
work item of the Transport Layer Security (TLS) WG of the IETF.

   Title:   TLS 1.2 is in Feature Freeze
   Authors: Rich Salz
Nimrod Aviram
   Name:draft-ietf-tls-tls12-frozen-03.txt
   Pages:   5
   Dates:   2024-12-09

Abstract:

   Use of TLS 1.3 is growing and fixes some known deficiencies in TLS
   1.2.  This document specifies that outside of urgent security fixes,
   new TLS Exporter Labels, or new Application-Layer Protocol
   Negotiation (ALPN) Protocol IDs, no new features will be approved for
   TLS 1.2.  This prescription does not pertain to DTLS (in any DTLS
   version); it pertains to TLS only.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-tls12-frozen-03.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-tls12-frozen-03

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: I-D Action: draft-ietf-tls-tls12-frozen-03.txt

[Salz, Rich]

This draft incorporates feedback from:
Rob Sayre
John Mattson
Bas Wasterbaan
David Benjamin
I also changed the 8447 reference to the 8447-bis draft.


On 12/9/24, 3:30 PM, "internet-dra...@ietf.org 
" mailto:internet-dra...@ietf.org>> wrote:


Internet-Draft draft-ietf-tls-tls12-frozen-03.txt is now available. It is a
work item of the Transport Layer Security (TLS) WG of the IETF.


Title: TLS 1.2 is in Feature Freeze
Authors: Rich Salz
Nimrod Aviram
Name: draft-ietf-tls-tls12-frozen-03.txt
Pages: 5
Dates: 2024-12-09


Abstract:


Use of TLS 1.3 is growing and fixes some known deficiencies in TLS
1.2. This document specifies that outside of urgent security fixes,
new TLS Exporter Labels, or new Application-Layer Protocol
Negotiation (ALPN) Protocol IDs, no new features will be approved for
TLS 1.2. This prescription does not pertain to DTLS (in any DTLS
version); it pertains to TLS only.


The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/


There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-tls12-frozen-03.html 


A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-tls12-frozen-03 

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

[Deirdre Connolly]

Pursuant to this thread, preliminary support for MLKEM768-only has been
merged into rustls (I contributed):

https://github.com/rustls/rustls/pull/2259

On Thu, Dec 5, 2024 at 4:10 PM Scott Fluhrer (sfluhrer)  wrote:

> How do we proceed with this draft?
>
>
>
> This draft is quite boring (which is good from a cryptographical
> perspective); it just says ‘take ML-KEM and insert it as a key agreement
> into TLS in the obvious way’.
>
>
>
> I understand that people want to discuss the hybrid KEM draft more
> (because there are more options there) – can we at least get the less
> controversial part done?
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze

[Sean Turner]

Just a reminder that this WG last call is still ongoing.

spt

> On Dec 3, 2024, at 16:26, Sean Turner  wrote:
> 
> This is the working group last call for TLS 1.2 is in Feature Freeze. Please 
> review draft-ietf-tls-tls12-frozen [1] and reply to this thread indicating if 
> you think it is ready for publication or not.  If you do not think it is 
> ready please indicate why.  This call will end on December 17, 2024.
> 
> Cheers,
> spt
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-agreement

[Blumenthal, Uri - 0553 - MITLL]

+1 for adoption

While I'm stronly against wide deployment of pure ML-KEM at this moment in
time, I'm very much in favour of adoption of this document, having
stable definitions for such codepoints, even if they will get doployed only
in closed networks is still useful. 

+1 for adoption. And I am perfectly fine with wide deployment of pure ML-KEM. 








smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Secdir last call review of draft-ietf-tls-svcb-ech

[tirumal reddy]

Reviewer: Tirumaleswar Reddy K
Review result: Ready with issues

I have reviewed this document as part of the SEC area directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Security area
directors.
Document editors and WG chairs should treat these comments just like any
other
last-call comments.

1. A SVCB RRSet containing some RRs with "ech" and some without is
   vulnerable to a downgrade attack: a network intermediary can block
   connections to the endpoints that support ECH, causing the client to
   fall back to a non-ECH endpoint.  This configuration is NOT
   RECOMMENDED.

Comment> Please mention scenarios where such mixed behavior may be
acceptable. Highlighting the exceptions would be helpful.

2. ECH ensures that TLS does not disclose the SNI, but the same
   information is also present in the DNS queries used to resolve the
   server's hostname.  This specification does not conceal the server
   name from the DNS resolver.  If DNS messages are sent between the
   client and resolver without authenticated encryption, an attacker on
   this path can also learn the destination server name.  A similar
   attack applies if the client can be linked to a request from the
   resolver to a DNS authority.

Comment> While authenticated encryption provides protection against active
attackers, the privacy benefits are negated if the DNS resolver itself is
malicious. It may be useful to recommend using trusted DNS resolvers.

3. It will be helpful to provide recommendations to endpoint
implementations not to mislead end-users that "ECH" would provide the same
level of security fully anonymizing solutions like Tor,  "ECH" may not
provide any privacy because of the reasons discussed in 2nd paragraph of
Security Considerations Section.

4. The discussion on the anonymity set could benefit from examples or
references that illustrate how traffic analysis might narrow it.

5. The behaviour recommendation for middleboxes acting as a TLS proxy
should be discussed.

Cheers,
-Tiru
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org