Nico Williams writes:
>If it's different then that's costing the server the resources to generate
>it, which is precisely what its operator didn't want when they enabled eDH
>key reuse.
It depends on what those resources are, at one end you've got proper DHE with
a full modexp required, at the
On Fri, Dec 07, 2018 at 06:31:21AM +, Peter Gutmann wrote:
> Aren't you going to get into an adversarial machine learning problem where
> your recogniser has to be smarter than the other side's DH-reuse code? In
> other words if the server just reuses the same DHE public value again and
>
Daniel Kahn Gillmor writes:
>the way i was going to write it that guidance was pretty dumb (i was thinking
>of just a hashtable combined with a fixed-size ring buffer to be constant-
>space and roughly constant-time, and hadn't even considered bloom filters),
>so i welcome suggested text.
On Fri, Dec 07, 2018 at 03:37:25AM +0300, Daniel Kahn Gillmor wrote:
> On Wed 2018-12-05 18:59:07 +, Stephen Farrell wrote:
> > it's feasible and not easily defeated.
>
> TLS endpoints can share their data (key material, cleartext, etc) with
> whoever they choose -- that's just how the
On Wed 2018-12-05 18:59:07 +, Stephen Farrell wrote:
> it's feasible and not easily defeated.
TLS endpoints can share their data (key material, cleartext, etc) with
whoever they choose -- that's just how the universe is implemented.
They can even do it out of band, on a channel that the peer
I am really surprised how the answers you don't like are systematically put on
denial. Can you explain me what leads you to think that some people here are
not concerned by the list of people you list? this is an assumption and the
wrong assumption.
Perhaps on the contrary we are concerned
On Thu, Dec 6, 2018 at 3:30 PM Viktor Dukhovni
wrote:
> > On Dec 6, 2018, at 4:08 PM, Andrei Popov 40microsoft@dmarc.ietf.org> wrote:
> >
> > Widespread deployment of draft-dkg-tls-reject-static-dh-01 and failing
> connections to "enterprise TLS" servers would probably qualify as
>
On Fri, Dec 07, 2018 at 12:04:02AM +, Andrei Popov wrote:
> > I don't think the TLS WG or IETF can win this skirmish.
>
> That's what I'm thinking as well, although I agree with the goals of
> draft-dkg-tls-reject-static-dh-01.
Yes. What we can, and IMO should do, is say that if you must
> I don't think the TLS WG or IETF can win this skirmish.
That's what I'm thinking as well, although I agree with the goals of
draft-dkg-tls-reject-static-dh-01.
Cheers,
Andrei
___
TLS mailing list
TLS@ietf.org
On Thu 2018-12-06 21:08:00 +, Andrei Popov wrote:
> In a specific quick test that I did, there was no significant perf
> impact with key reuse time > 1 sec. And I could probably get it down
> to sub-seconds on my HW. But HW specs differ between TLS servers; our
> current "ephemeral" key
> On Dec 6, 2018, at 4:08 PM, Andrei Popov
> wrote:
>
> Widespread deployment of draft-dkg-tls-reject-static-dh-01 and failing
> connections to "enterprise TLS" servers would probably qualify as "essential
> circumstances", at least to some operators.
I don't think the TLS WG or IETF can win
On Thu, Dec 6, 2018 at 12:33 PM Daniel Kahn Gillmor
wrote:
> So it's conceivable that truly malicious servers would do this, of
> course, but they might also just publish the master secret on twitter
> too, and the client wouldn't know how to detect that inband either. But
> for the misbehavior
On Thu 2018-12-06 02:10:06 +, Andrei Popov wrote:
> In our tests, we see significant drop in handshakes/sec on a busy TLS
> server with ephemeral DH share reuse time < 1 sec.
hm, thinking about this optimization approach, i would really like to
know what implementations are doing this. It
Hi Andrei--
On Thu 2018-12-06 02:10:06 +, Andrei Popov wrote:
> I like the intent of draft-dkg-tls-reject-static-dh-01, but this part will
> cost servers some perf:
>
>"Given the concerns in Section 2 and the necessary client mitigations
>in the subsections above, servers need to
Hello Eric,
> Are there other concerns
No, there are no other concerns, these two issues addresses my findings.
Mit freundlichen Grüßen / Best regards
Achim Kraus
(INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen |
GERMANY | http://www.bosch-si.com
On Thu, Dec 6, 2018 at 12:19 AM Kraus Achim (INST/ECS4) <
achim.kr...@bosch-si.com> wrote:
> Hi List,
>
>
>
> I put some comments and question on the github page,
>
>
>
> https://github.com/tlswg/dtls-conn-id/issues/15
>
This is IANA considerations. I will fix.
>
The WGLC for “DTLS 1.3" is now complete. We thank Martin
Thomson for his review. There are some issues that need to
be addressed. We are going to let the authors sift through
them over the next couple of week and we will bring back
any to the WG that requires discussion.
spt
> On Nov 7, 2018,
Hi List,
I put some comments and question on the github page,
https://github.com/tlswg/dtls-conn-id/issues/15
https://github.com/tlswg/dtls-conn-id/issues/25
and still wait for feedback and comments. FMPOV, the last changes
https://github.com/tlswg/dtls-conn-id/pull/13
seems to be not
18 matches
Mail list logo
