Hi,
It appears that there may be a need to revert to the
old way of sending Diffie-Hellman parameters that
the server generates. I see that TLS 1.3 removed
this capability*; is there any way to add it back?
Mike
*From RFC 8446:
- Other cryptographic improvements were made,
including changin
On Fri, Oct 9, 2020, at 11:17, Christopher Wood wrote:
> Michael, since your question is more related to the cryptographic
> primitives used by TLS than the protocol itself, the chairs encourage
> you to continue this discussion on the CFRG mailing list [2].
>
> Thanks,
> Chris, on behalf of th
On Mon, Oct 12, 2020 at 12:36:06PM -0400, Michael D'Errico wrote:
>
> It appears that there may be a need to revert to the
> old way of sending Diffie-Hellman parameters that
> the server generates. I see that TLS 1.3 removed
> this capability*; is there any way to add it back?
The Diffie-Hellma
I suggest that custom parameters should be allowed, and documented as
completely under user/administrator responsibility.
Ensuring that a custom modulus is not "too small" or "too large" (etc.) in that
case is not your problem or your business.
On 10/12/20, 13:32, "TLS on behalf of Ilari Liu
Would it be possible to define a new dual-DH exchange
where you do one with server-supplied parameters, and
a second one with client-supplied parameters, so if one
is broken or sabotaged the connection is still secure?
Mike
On Mon, Oct 12, 2020, at 13:35, Blumenthal, Uri - 0553 - MITLL wrote:
>
Hi Mike,
On Sat, Oct 10, 2020 at 01:29:13PM -0400, Michael D'Errico wrote:
> On Fri, Oct 9, 2020, at 17:22, Benjamin Kaduk wrote:
> > [...] The behavior we should demand from our cryptographic
> > constructions is that the cryptography itself correctly returns
> > "valid" or "invalid" based on th
Hi Achim,
On Sun, Oct 11, 2020 at 07:43:14PM +0200, Achim Kraus wrote:
> Hi Watson,
>
> > The doubt is because of where it appears not that it appears. If every
> > value was preceded by its length the encoding would obviously be
> > injective.
>
> I hope, this is just a "typo" or "mistake".
>
>It appears that there may be a need to revert to the
old way of sending Diffie-Hellman parameters that
the server generates.
Can you explain why? Something stronger than "I think that ..." is probably
needed to convince the WG.
___
TLS
On Sat, Oct 10, 2020 at 09:13:51AM +0200, Achim Kraus wrote:
> Hi Ben,
>
> >
> > To be frank, I'm actually surprised that this is even seen as a matter for
> > discussion.
>
> As developer, I'm surprised, that this discussion now spans a couple of
> years, starting on summer 2018 with:
>
> https
Hi all,
Victor and I recently published draft-vvv-tls-alps-01. It has a couple of
changes that I wanted to get the WG’s thoughts on. The changes are
switching the bespoke ClientApplicationSettings message to a client
EncryptedExtensions message and clarifying the 0-RTT handling.
https://tools.iet
Ilari Liusvaara writes:
>The Diffie-Hellman support in TLS 1.2 is severly broken. There is no way to
>use it safely on client side. This has lead to e.g., all the web browers to
>remove support for it.
It's actually pretty simple, don't use toy key sizes. Many implementations
were never vulnera
In some cases toy key sizes are necessary.
E.g., classes where your students break encryption because the keys are weak or
small.
Regards,
Uri
> On Oct 12, 2020, at 19:42, Peter Gutmann wrote:
>
> Ilari Liusvaara writes:
>
>> The Diffie-Hellman support in TLS 1.2 is severly broken. There
Hi Ben,
Just as forecast:
Without agreement, that the CIDs must be encoded using deterministic
interpretation, which in my opinion obsoletes these "number games",
next Summer either Raccoon or Kenny will write up their next
"time side channel attack" on this.
(The ambiguity will end up in try
Hi Ben,
Sure, there's pretty standard common-knowledge guidance, though I'm not
sure it's documented anyplace particularly discoverable:
- include in the MAC as much application/protocol context and protocol
fields as you can without breaking operation of the procotol
- ensure that the mappi
On 2020-10-12 19:28, Ilari Liusvaara wrote:
On Mon, Oct 12, 2020 at 12:36:06PM -0400, Michael D'Errico wrote:
It appears that there may be a need to revert to the
old way of sending Diffie-Hellman parameters that
the server generates. I see that TLS 1.3 removed
this capability*; is there any w
Hi,
There was a reason custom DH parameters were removed.
Custom DH parameters were the source of plenty of problems.
I suggest reading:
https://blog.hboeck.de/archives/841-Diffie-Hellman-and-TLS-with-nonsense-parameters.html
https://eprint.iacr.org/2016/644
https://www.openssl.org/news/secadv/20
16 matches
Mail list logo
