Salz, Rich writes:
>Do we need a short RFC saying “do not use static DH” ?
There are two things arguing against it:
Reason the first: Static-ephemeral DH was a dumb idea when it was proposed in
X9.42 more than twenty years ago and hasn't gotten any better since then. If
people haven't learned
Am 10.09.20 um 11:23 schrieb Peter Gutmann:
Reason the second: Telling people not to use static-ephemeral DH will mean
telling them not to use 25519 key exchange, which will make their heads
asplode.
Peter.
So, risking damaged heads:
Does using x25519 for ECDHE is significant less secure
than
From: TLS On Behalf Of Salz, Rich
> Do we need a short RFC saying “do not use static DH” ?
Don’t TLS 0-RTT and ESNI/ECH via HPKE use a type of (semi)static ECDH? If so,
then an RFC to ban static (EC)DH in TLS would need to be very clear about not
referring to these use cases of static ECDH.
On 2020-09-02 11:05 a.m., Joe Clarke (jclarke) wrote:
Hello, opsawg. This draft as underwent a number of revisions based on reviews
and presentations at the last few IETF meetings. The authors feel they have
addressed the issues and concerns from the WG in their latest posted -05
revision.
Dan,
What you suggest, namely, DH for both static and ephemeral keys is what
OPTLS was about and this approach is now specified in
https://tools.ietf.org/html/draft-ietf-tls-semistatic-dh-01.
I was never too happy with the name semi-static for such protocol, and
people may think that if static i
The Transport Layer Security (tls) WG will hold
a virtual interim meeting on 2020-09-21 from 08:00 to 09:00 America/Los_Angeles
(15:00 to 16:00 UTC).
Agenda:
ECH Issue Discussion
https://github.com/tlswg/draft-ietf-tls-esni/issues
Information about remote participation:
https://ietf.webex.com/i
Much as I hesitate to disagree with Peter:
> Reason the second: Telling people not to use static-ephemeral DH will mean
> telling them not to use 25519 key exchange, which will make their heads
> asplode.
Do you mean this because people will confuse DH with ECDHE ?
__
This is primarily an active attack, but not purely so. Clearly the MITM is an
active attacker, but there are situations in QUIC (and DTLS, I presume) where a
ClientHello gets retransmitted. Depending on server infrastructure, the client
might get two different responses. This isn’t limited to
Hi Mike,
I've since updated the proposal to address the replay attack, but not
Christian's MITM attack:
https://github.com/tlswg/draft-ietf-tls-esni/pull/287
A quick question about Chrisitian's suggestion of using the "key_shares" to
derive the hint. I believe a slightly stronger variant of the M
On Thu, Sep 10, 2020 at 11:52 AM Mike Bishop wrote:
> This is primarily an active attack, but not purely so. Clearly the MITM
> is an active attacker, but there are situations in QUIC (and DTLS, I
> presume) where a ClientHello gets retransmitted. Depending on server
> infrastructure, the clien
Certainly it’s better for the server if it can be consistent, especially if it
expects multi-packet first flights. If the same back-end sees both, it can
discard the second, and that’s what I’d expect most of the time. But here’s
what I think is possible:
The client sends an Initial packet
On Thu, Sep 10, 2020 at 2:21 PM Mike Bishop wrote:
> Certainly it’s better for the server if it can be consistent, especially
> if it expects multi-packet first flights. If the same back-end sees both,
> it can discard the second, and that’s what I’d expect most of the time.
> But here’s what I
On 9/10/2020 12:43 PM, Christopher Patton wrote:
> Hi Mike,
>
> I've since updated the proposal to address the replay attack, but not
> Christian's MITM attack:
> https://github.com/tlswg/draft-ietf-tls-esni/pull/287
>
> A quick question about Chrisitian's suggestion of using the
> "key_shares" t
On Fri, Sep 11, 2020, at 08:11, Eric Rescorla wrote:
> OK, this can't happen in DTLS because the CID management works differently.
Right.
> While it's not clear to me that QUIC explicitly prohibits this (it
> would be prohibited if CRYPTO frames were STREAM frames because of
> draft-ietf-tls-qu
Hi Christian,
No, I don't think the server can detect ECH usage by doing that. The
> client will complete the exchange as if connected to the server. The
> client's response would pretty much the same as if the server's response
> had not been modified, and the MITM will not be able to test whethe
Achim Kraus writes:
>Does using x25519 for ECDHE is significant less secure than using it with
>e.g. secp384r1?
The NIST curves AFAIK are never used that way, it's only done with 25519
(there was something about it in an OpenPGP draft, but I think GPG went
straight to 25519 and only used ECDSA f
Salz, Rich writes:
>Do you mean this because people will confuse DH with ECDHE ?
See my reply to Achim, it's not that but because banning static-ephemeral
(EC)DH will also affect all the cases where it's being applied as it if were
RSA.
Which, given that it's such a footgun would IMHO be a good
17 matches
Mail list logo
