On Fri, Dec 13, 2024 at 11:29 AM Sophie Schmieg wrote:
> Answers inline. I will only bother to answer questions others might have
> as well, and ignore the rather laughable legal speculation.
>
I don't agree with Daniel, but let's not say words like "laughable". It's
just an insult.
I think you
Adding antitrust-pol...@ietf.org; but I'm replying to a tls@ietf.org
message, and the antitrust issues here are clearly relevant to an
ongoing TLS discussion, so I'm also keeping tls@ietf.org.
Rob Sayre writes:
> I think you can find Brad Biddle saying "the process is fine" about all of
> these le
Hi all,
> Peter Gutmann wrote:
>
> Richard Barnes writes:
>
>> 3 seems like it encodes the expectation of most people for what the protocol
>> means. If you're using a cipher suite labeled something like "ECDHE", it's
>> reasonable to expect that it's actually ephemeral,
>
> I'd support 3 as
I prefer 2.
On Thu, Dec 12, 2024 at 6:37 PM Joseph Salowey wrote:
> Currently RFC 8446 (and RFC8446bis) do not forbid the reuse of ephemeral
> keys. This was the consensus of the working group during the development
> of TLS 1.3. There has been more recent discussion on the list to forbid
> re
Hiya,
On 12/12/2024 17:59, Richard Barnes wrote:
My preference order would be 3 > 1 >> 2.
I agree with the above for reasons already stated on the list.
Cheers,
S.
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
On Thu, 12 Dec 2024 at 21:37, Joseph Salowey wrote:
>
> Currently RFC 8446 (and RFC8446bis) do not forbid the reuse of ephemeral
> keys. This was the consensus of the working group during the development of
> TLS 1.3. There has been more recent discussion on the list to forbid reuse
> for ML-
Answers inline. I will only bother to answer questions others might have as
well, and ignore the rather laughable legal speculation.
> "I do not see a security concern with having the option for RC4 in TLS.
> TLS has ways of negotiating algorithms. If one side believes RC4 to be
> insufficiently
Open questions about ephemeral key reuse (and I don't know the answers; that's
why they're open questions) - the answers to these questions may help us guide
us as to whether to forbid it or not:
- To what extent do the proofs of security for TLS 1.3 depend on the non-reuse
of key shares (eithe
On Fri, Dec 13, 2024 at 08:24:24PM -0800, Joseph Salowey wrote:
> You continue to violate list policy with unprofessional commentary on other
> participants' motivations and repeatedly raising points that are out of
> scope. Please stop this behavior. This is the last warning before we will
> ta
Hi Dan,
You continue to violate list policy with unprofessional commentary on other
participants' motivations and repeatedly raising points that are out of
scope. Please stop this behavior. This is the last warning before we will
take action and temporarily ban you from the list; see BCP 94 [0].
Sophie Schmieg writes:
> I do not see a security concern with having the option for pure ML-KEM in
> TLS. TLS has ways of negotiating algorithms, if one side believes ML-KEM to
> be insufficiently secure, they can negotiate 0x11EC (which equally should
> be adopted).
"I do not see a security conce
> > > Security is not easy to evaluate. Asking random users to make
> > > security decisions is a recipe for disaster. Blaming users for the
> > > resulting failures simply perpetuates the problem.
> And you would have a point if this was a decision between a known broken
> scheme and a known to be
> The _proposed_ rubber-stamping is to let NSA buy TLS WG endorsement of
this spec.
No. I proposed this document because I want to be able to negotiate PQ-only
key establishment without hybrid. It got codepoints and now is getting more
support, which is nice. I wrote it because I wanted to use it.
On Fri, Dec 13, 2024, at 23:19, Stephen Farrell wrote:
> On 12/12/2024 17:59, Richard Barnes wrote:
>> My preference order would be 3 > 1 >> 2.
>
> I agree with the above for reasons already stated on the list.
As do I.
___
TLS mailing list -- tls@ietf.
Deirdre Connolly writes:
> I wrote it because I wanted to use it. Enough.
Don't proposals to IETF always claim that there will be users? This is
content-free, and not a valid argument for IETF endorsement.
Back in March, the first message announcing the draft similarly didn't
give a technological
15 matches
Mail list logo
