Re: [Cfrg] NSA sabotaging crypto standards

[Watson Ladd <[e-mail]>]

On Thu, Feb 6, 2014 at 10:48 AM, Paul Hoffman <[e-mail]> wrote:
> On Feb 6, 2014, at 9:00 AM, Watson Ladd <[e-mail]> wrote:
>
>> IETF working groups will follow suit if they see that some new
>> protocol is documented by the CFRG.
>
> Can you give examples of that? Having been active in many IETF WGs for 15+ years, I can't think of one, but I could have forgotten some.

Dragonfly in TLS was the first time this happened. Had Rene Struik not
noticed that CFRG hadn't done anything, life would be interesting.
My understanding was that CFRG existed so that IETF WGs without
cryptographers could borrow some temporarily from us. That's what the
HTTP
auth people are doing, and what TLS did with Dragonfly.

>
>> That's the role
>> the CFRG exists to play: supporting IETF WGs when they have to
>> evaluate crypto.
>
> Evaluating crypto is quite different than creating "some new protocol". The CFRG most often evaluates existing crypto protocols and modes, it doesn't create them.

I think we're saying the same thing: IETF WG wants a protocol that
does blah. They look around and see the proposals blah1, blah2 etc.
exist.
Then one of them gets picked. Whether this is defining a new protocol
or evaluating the existing blah1, blah2, etc. is I think more semantic
than anything else. A useful evaluation results in changes to address
found deficiencies, or a statement that there are none and will be
none. The easiest time to replace a broken mechanism is when it is
being designed, before it is deployed. If we are playing catchup to
deployment, the only thing we can say is "we're doomed" when we find a
problem.

There is also the everpresent turning the paper into a spec. This is
fairly routine for most protocols, but the details matter, and can
completely change what actually is going on. SSL v3 looked like it was
using CBC mode, but because they decided to use chained IV's, actually
were doing something completely different.

>
>> Furthermore, if we aren't actually
>> producing documents meant to say "This is X, and X is good" for some
>> definition of good, what are we doing here?
>
> Lots of things:
>
> - This is X, and while X is good, doing Y in X would be very bad
>
> - This is X, and we have some shaky feelings about X, but we're totally fine with Z, which can be used in most of the same places
>
> - Current IETF protocols use X, but X is now out of favor for these reasons; please strongly consider using Z
>
> In the latter two cases, Z is not "some new protocol", they are existing ones that have been studied.

Are any of the CFRG WG drafts/IRTF publications actually of this form?
I really don't know: from my review of the mailing list
the CFRG did very little up until last year or so. I agree these are
also documents that require production, especially when some ancient
protocol hasn't been studied because it isn't as attractive a target
as TLS. We need some sort of idea how to do this kind of review
systematically.
I've tried by reviewing all cfrg drafts, but there are some emails I'm
behind on, and there is no way I can do all 7 thousand RFCs in a
reasonable amount of time.

Sincerely,
Watson Ladd