[TLS] Re: Adoption call for RFC 9147bis

[Muhammad Usama Sardar]

On 02.12.24 18:38, Joseph Salowey wrote:

If you object to the adoption of this document please respond to this 
thread by December, 9 2024.


Based on this, I would have expected only those objecting to respond. 
But since those supporting the draft are also responding, so here goes 
my support for the draft. I fully support adoption.


I agree with Russ and John, and would look forward to the FATT review to 
know their opinion on whether one should include KeyUpdate and 
post-handshake parts in the formal models.




smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[John Mattsson]

I agree with David, I think “and provides excellent security as-is” should be 
removed.

John

From: David Benjamin 
Date: Wednesday, 4 December 2024 at 18:57
To: John Mattsson 
Cc: Salz, Rich , Sean Turner , TLS List 

Subject: Re: [TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze
Talking about providing "excellent security" also will get out-of-date and/or 
subjective once someone decides post-quantum, or any other 1.3-only 
improvement, is the bar for "excellent". I would suggest just not having the 
draft opine on such things when it doesn't need to.

We could just delete the first paragraph altogether and start the document:

> TLS 1.3 [TLS13] is in widespread use and fixes many known deficiencies with 
> TLS 1.2 [TLS12], such as encrypting more of the traffic so that it is not 
> readable by outsiders and removing most cryptographic primitives now 
> considered weak. Importantly, TLS 1.3 enjoys robust security proofs and 
> provides excellent security as-is.

On Wed, Dec 4, 2024 at 12:42 PM John Mattsson 
mailto:40ericsson@dmarc.ietf.org>>
 wrote:
That would address your concern.

John

From: Salz, Rich 
mailto:40akamai@dmarc.ietf.org>>
Date: Wednesday, 4 December 2024 at 15:21
To: John Mattsson 
mailto:john.matts...@ericsson.com>>, Sean Turner 
mailto:s...@sn3rd.com>>, TLS List 
mailto:tls@ietf.org>>
Subject: Re: [TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze
>TLS 1.3 enjoys robust
>security proofs and provides excellent security as-is.
as-is, TLS 1.3 does not provide excellent security for long-term connections.
It removes essential features such as asymmetric rekeying and reauthentication.

Would changing it to “provides excellent security for many use-cases as-is” 
address your concern?  Or “can provide excellent security”?  Or does that open 
up the case where people say “where does not it apply?”  Would it be better to 
just remove the “and provides” phrase altogether?

___
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: MLKEM or Khyber KX

[Viktor Dukhovni]

On Sat, Nov 02, 2024 at 07:12:02AM +, John Mattsson wrote:

> Eric Rescorla wrote:
> >Is reuse of ML-KEM keys worse in some way than the reuse of ECDHE keys?
> 
> No reuse of ephemeral keys is always bad.

But ML-KEM is specifically designed (IND-CCA2, via FO transform) to
support key reuse, without immediate advantage to the attacker.

And (though it isn't exactly TLS 1.3) there are ideas in place like
KEMTLS, in which the server key is actually stable (used as both
a KEM and for authentication, obviating the need for separate signing
of the key exchange).

And so long as the client's encap ciphertext is different each time,
there's no issue with linking connections.

So perhaps the story is a bit more nuanced than "key reuse is always
bad", but of course any design that incorporates key reuse needs to
take care to do it correctly.

Specifically, in stock TLS 1.3, (with the client side generating keys,
and doing "decap") it seems that key reuse is not particularly
compelling, and servers don't have a key they can reuse, "encap" just
consumes a nonce and the client's public key.

-- 
Viktor.

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

[TLS] Re: Adoption call for RFC 9147bis

[Ben Smyth]

On Thu, 5 Dec 2024, 09:29 Muhammad Usama Sardar, <
muhammad_usama.sar...@tu-dresden.de> wrote:

> On 02.12.24 18:38, Joseph Salowey wrote:
>
> > If you object to the adoption of this document please respond to this
> > thread by December, 9 2024.
>
> Based on this, I would have expected only those objecting to respond.
> But since those supporting the draft are also responding, so here goes
> my support for the draft. I fully support adoption.
>
> I agree with Russ and John, and would look forward to the FATT review to
> know their opinion on whether one should include KeyUpdate and
> post-handshake parts in the formal models.
>

If they aren't in the model, then analysis is only good up to KeyUpdate.
(OpenJDK got KeyUpdate wrong, there were use cases with no security.)

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

[TLS] Re: MLKEM or Khyber KX

[Loganaden Velvindron]

Agreed. I hope that this becomes a MUST.

On Fri, 1 Nov 2024 at 22:30, John Mattsson
 wrote:
>
> >and would warmly welcome it being a MUST in the IETF specification of the 
> ML-KEM TLS hybrids.
>
>
> +1
>
> Let’s try to make that happen
> https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/pull/25
>
> ___
> 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: draft-connolly-tls-mlkem-key-agreement

[Russ Housley]

I hope so.  Can we start an adoption call?

Russ

> On Dec 5, 2024, at 4:08 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] draft-connolly-tls-mlkem-key-agreement

[Scott Fluhrer (sfluhrer)]

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] Re: MLKEM or Khyber KX

[Watson Ladd]

On Thu, Dec 5, 2024 at 7:31 AM Viktor Dukhovni  wrote:
>
> On Sat, Nov 02, 2024 at 07:12:02AM +, John Mattsson wrote:
>
> > Eric Rescorla wrote:
> > >Is reuse of ML-KEM keys worse in some way than the reuse of ECDHE keys?
> >
> > No reuse of ephemeral keys is always bad.
>
> But ML-KEM is specifically designed (IND-CCA2, via FO transform) to
> support key reuse, without immediate advantage to the attacker.

Having two identical Client Hellos is bad for the security proofs in
TLS. While MLKEM keys aren't the only part of the ClientHello,
(ClientRandom is also), reuse potentially breaks assumptions in the
symbolic analysis. That's different from a break of IND-CCA2: IND-CCA2
is fine if you send the same message again and get the same answer,
while having two of the same session is a problem for TLS. (What is
the meaning of "same"? Good question).

>
> And (though it isn't exactly TLS 1.3) there are ideas in place like
> KEMTLS, in which the server key is actually stable (used as both
> a KEM and for authentication, obviating the need for separate signing
> of the key exchange).

Different things are different. KEMTLS uses an ephemeral KEM key at
the very start. Importantly there's a complete (actually two complete)
Tamarin proofs of claimed security properties.

>
> And so long as the client's encap ciphertext is different each time,
> there's no issue with linking connections.
>
> So perhaps the story is a bit more nuanced than "key reuse is always
> bad", but of course any design that incorporates key reuse needs to
> take care to do it correctly.
>
> Specifically, in stock TLS 1.3, (with the client side generating keys,
> and doing "decap") it seems that key reuse is not particularly
> compelling, and servers don't have a key they can reuse, "encap" just
> consumes a nonce and the client's public key.
>
> --
> Viktor.
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org



-- 
Astra mortemque praestare gradatim

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

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

[John Mattsson]

+1

From: Russ Housley 
Date: Thursday, 5 December 2024 at 22:20
To: Scott Fluhrer (sfluhrer) 
Cc: IETF TLS 
Subject: [TLS] Re: draft-connolly-tls-mlkem-key-agreement
I hope so.  Can we start an adoption call?

Russ


On Dec 5, 2024, at 4:08 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