Subject: Re: [perpass] [Cfrg] CFRG and thwarting pervasive montoring

From: Watson Ladd <[email-masked]>
Date: Sun, 29 Dec 2013 17:11:37 -0500

On Sun, Dec 29, 2013 at 4:26 PM, Stephen Farrell
<[email-masked]> wrote:
>
>
> On 12/29/2013 09:12 PM, Paul Hoffman wrote:
>> On Dec 29, 2013, at 11:12 AM, Stephen Farrell
>> <[email-masked]> wrote:
>>
>>> . . .
>>
>>> I would love to see ongoing detailed work within CFRG as to how to
>>> counter pervasive monitoring.
>>
>> Wearing your perpass hat, how can CFRG help? I ask this because I
>> have seen little on the perpass mailing list that indicated that an
>> even minor problem has been lack of crypto, or the use of crypto that
>> is thought to be breakable. What type of crypto research or
>> assessment would help perpass?

Sending to perpass to get feedback on this question.

>>
>> Note that deprecating the use of crypto that is widely known to be
>> broken is the purview of IETF WGs, not the CFRG. The relevant WGs
>> (particularly TLS) seem to already be doing that.

I don't agree with this assessment: the BCP Yaron Sheffer wrote on
depreciating RC4 got kicked
to the newly formed UTA WG, which has done nothing with it. The
biggest changes here have
been AGL pushing stuff into Chrome, but he can't do the server side
nearly as easily. It's been
a controversial topic in the TLS WG, even with Marsh Ray and AGL pushing for it.

>
> One question might be whether some modes of operation are
> really inherently more likely to have side-channels in their
> implementation or not and whether the impact of that might
> be practically usable by an attacker.

That assumes crypto is being used, and can hide the relevant information.
DNS is still in cleartext, and even HTTPS reveals what sites you are looking at.
The only fixes are PIR protocols, onion routing, and related tricks. We can also
try to reduce what is revealed: version numbers, configurations, and options can
be quite interesting for targeting, particularly if they are linkable
across sessions.

Side-channels are fixable with good, freely usable implementations: I
don't understand
why we are concerned with bad implementers. (Of course, the standard
needs to allow
a good side channel free implementation.) The lazy would rather copy
than innovate incorrectly.

Anyway, AES-GCM has side channel issues, but with HMAC+Salsa20/Chacha
or Chacha/Poly1305
it is easier to avoid them with as they have efficient circuits which
CPUs can do.

>
> Another might relate to whether things like nonces might
> provide a way for borked implementations to leak key bits
> and if so, whether there are practical ways for susceptible
> protocols to mitigate that, or bits of advice that should
> be included in such protocol specs. (And finding some
> susceptible protocols would be cool too if CFRG folks were
> willing.)

As in leak a key via the bits of an IV? That's not borked but
deliberate. For signing quite a few covert channels are known in
ECDSA. This is rumored to be an issue in the Test Ban Treaty negotiations,
but good luck finding out about that!

The easy countermeasure for some algorithms is to use nonces that are
implicit, incrementing with message number. That way
each peer enforces the algorithm on the other. Robert Ransom deserves
credit for this recognition AFAIK,
but I am sure this has been done before.

>
> I'm sure clever folk can come up with more once they start
> to think about it.
>
> S.
>
>
>>
>> --Paul Hoffman
>>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Leif Johansson <[email-masked]>
Date: Mon, 30 Dec 2013 14:16:04 +0100

> 29 dec 2013 kl. 23:11 skrev Watson Ladd <[email-masked]>:
> 
> to the newly formed UTA WG, which 

huh? who did what to what?

the uta list is just barely open and we've hardly hardly had time to get organized, let alone decide which drafts to take on.

lets take a deep breath & settle down

      Leif

> has done nothing with it. The

---

From: Stephen Kent <[email-masked]>
Date: Mon, 30 Dec 2013 12:06:54 -0500

Watson,
> I don't understand why we are concerned with bad implementers. 
because the world is full of implementation errors?

> but good luck finding out about that!
In the TBT context the focus was exactly the opposite of what you
suggested, according to my recollection. The parties to the treaty
(the US and the Soviet Union) wanted to make sure that the signed
data being sent didn't have any covert exfiltration capabilities.
> each peer enforces the algorithm on the other.
Many years ago we explored the issue of using sequence numbers in
ESP in lieu of random IVs. One problem is that, from a security
assurance perspective, the software (or hardware) that manages
sequence numbers is usually outside the perimeter that is evaluated
for crypto alg security. Thus, if one used an ESP sequence number
as an IV, an implementation would not qualify as FIPS 140-x
compliant, unless most (all) of the ESP implementation were part
of the evaluation. That was not desirable side effect of an
implicit IV design. There were other problems, some of which were
IPsec-specific, that also caused us to stick with random IVs. Finally,
for very high speed implementations (hardware) there are some
advantages to allowing a sender to choose it's own approach to IV
generation.

Steve