Subject: Re: [Cfrg] Security proofs v DH backdoors

From: Peter Gutmann <[email-masked]>
Date: Tue, 1 Nov 2016 11:15:41 +0000

Ilari Liusvaara <[email-masked]> writes:

>Do the devices need to interop with web browsers?

The devices need to talk to each other, and comply with various SCADA
standards (IEC 62351-3 is one that springs to mind, but there are lots of
industry-specific standards and profiles).  What web browsers do ranks some
way down the list of priorities, about the level of an also-ran consideration.

>- If no, then you should be using top-edge TLS or something non-TLS that
>  is competently designed (esp. on constrained environments, as TLS is
>  not very economical there, even with pure-PSK).

This was more or less the same response that some embedded folks got on the
HTTP/2 list when they asked for some very minor changes to make HTTP/2 usable
with embedded, "let them eat HTTP 1.1".  The people driving HTTP/2 basically
said "we don't care about you, we're only designing for the web" (thus the
tongue-in-cheek name of HTTP/2, "HTTP4Google").  This is probably also why
there are approximately, oh, zero embedded folks contributing to the TLS list
(there are several in read-only mode, I'm not aware of anyone contributing
publicly).

>What libraries would implement that? 

Implement what?

Peter.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 1 Nov 2016 07:22:36 -0700

<chop>
>>What libraries would implement that?

TLS-LTS. What is the benefit over adopting TLS 1.2 with the changes
made by the UTA profile? I don't see any benefit, especially given the
amount that gets changed by LTS for no reason.

>
> Peter.
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 2 Nov 2016 00:50:47 +0000

Watson Ladd <[email-masked]> writes:

>I don't see any benefit, especially given the amount that gets changed by LTS
>for no reason.

Like what?  Most of it is just saying that a bunch of optional negotiated-by-
extension features that improve security should be mandatory (in other words
it's stuff that's already implemented, you just don't need to negotiate each
one piecemeal any more), and pretty much every change there is to address
things that have been security or interop issues in the past.  Another name
for it might be TLS-with-lessons-learned.

(This discussion would probably be better off-list, not sure if it's relevant
for CFRG).

Peter.

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 2 Nov 2016 12:05:12 +0000

Hi Dan,

Bringing this thread back to where it started...

On 25/10/2016 14:30, "Cfrg on behalf of Ilari Liusvaara"
<[email-masked] on behalf of [email-masked]> wrote:

>On Tue, Oct 25, 2016 at 01:10:16PM +0000, Dan Brown wrote:
>> How do the 3 recent IACR eprints on FFDH backdoors‎ reconcile with
>> past security proofs for TLS, SSH, etc?
>> 
>> Some guesses: (1) the attacks are outside the security definitions
>> (=> attacks not so important?), (2) the proofs assume strong FFDH
>> groups plus validation, etc.
>
>I guess the proofs assume strong FFDH groups, such that dlog and
>dh attacks are infeasible.

I can confirm that this is the correct explanation, at least for TLS.

For example, the security proof* for static DH ciphersuites in [1, Section
7] assumes that a certain CDH-like assumption holds (specifically, the
PRF-ODH assumption, which concerns the combination of the KDF used in TLS
and the DH problem).

This assumption is stronger than the assumption that the DLP is hard in
the specific group in which the protocol is run.

The proof in [1] also assumes group membership tests are carried out
(which, as has been discussed on this thread, is a problem for TLS, where
the server cannot tell the client anything about the group, not even its
claimed order). 

In the group instances under discussion, PRF-PDH is not hard for an
adversary who has the trapdoor/backdoor information.

Cheers,

Kenny 

---
*Other proofs for this and other modes are available in the literature.

[1] Hugo Krawczyk, Kenneth G. Paterson, Hoeteck Wee: On the Security of
the TLS Protocol: A Systematic Analysis. CRYPTO (1) 2013: 429-448

>
>I think there was one TLS implementation that tries to verify the
>groups sent (of course, not all can be verified, even if those
>aren't maliscously constructed).
>
>And the backdoors in one of the papers was about constructing
>prime such that one can use faster special case for dlogs. That
>can't be easily discovered, even if one somehow can obtain the
>group order. So one can't validate against it.
>
>
>-Ilari
>
>

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 2 Nov 2016 12:08:12 +0000

Hi

>(This discussion would probably be better off-list, not sure if it's

It's not irrelevant to CFRG, but neither does it reflect the topic with
which the thread started. Probably best taken off-list now, if you want to
continue that particular discussion.

Thanks,

Kenny