Re: [Cfrg] Requesting removal of CFRG co-chair

[Stephen Farrell <[e-mail]>]

Hiya,

On 12/24/2013 04:40 AM, Watson Ladd wrote:
> On Mon, Dec 23, 2013 at 10:12 PM, Stephen Farrell
> <[e-mail]> wrote:
> 
>> transparency we have. And I hope we (the IETF and IRTF) maintain
>> what is much more a core principle which is to not be driven by
>> irrational perception but to pay most attention to engineering and
>> science. (Whilst not being "pure" in any respect:-)
> 
> There is a great email from Phil Rogaway to the TLS WG circa 1995
> begging them to use ETM.
> They don't. The result is BEAST and Lucky13. How exactly is this
> paying attention to science?

Opinions about EtM were different in 1995 as I recall.
I'm not myself sure that an EtM variant of TLS would not
have had similar instances of problems - the evolution of
attacks on TLS has been interesting and I hope we've all
learned a lot of lessons from what is really the first time
we've scaled out deployment of a security protocol to that
extent.

> At IETF 88 the TLS WG didn't endorse a single solution to attacks
> currently viable against TLS 1.2 They couldn't even
> publish a "don't use RC4" document. The Best Current Practices
> document addressing this issue is languishing in
> a working group made specifically for this document, with no activity
> since September.
> The draft author has no clue why.

The above is inaccurate. Yaron wanted their draft in UTA. And
languishing since September is laughable. Even the TLS renego
bug RFC took 4 months, and that was much more of a deal than
Yaron's draft. (Yaron's and the other work to be done in UTA
are very important, but don't rise to that level.)

> Is it seriously too much to ask you to put some pressure on UTA and
> TLS to get these things fixed ASAP?

You misunderstand how the IETF works. I can't tell anyone what
to do and expect it to happen. (Luckily, because I'm wrong about
stuff just as often as others;-)

The UTA WG was formed within about a month of IETF-88. That is
lightening fast for this-decade's IETF. (We might bemoan that,
but that's where we are.) That speed was partly as a result of
encouragement from me and other members of the IESG, but the
real impetus comes from the community, not the leadership.

I think that there are fair criticisms to be made about the rate
of progress in TLS, and those have been made on that list and
Sean (the responsible AD) and the chairs are working to improve
matters. I'm confident they will.

But to understand that, you need to take into account things
like the deployment rate for TLS 1.2 and the factors that impacted
on that. Most of those are not under the control of the TLS WG,
never mind its chairs. (Again, the IETF and IRTF are volunteer
organisations - demands for action don't make sense there.)
But in any case, that's a topic for the TLS list and not here.

> 
> Currently the only ID with a shepherd is draft-mcgrew-tls-aes-ccm-ecc.
> Apparently, introducing another secure ciphersuite for
> specialized applications (in this case embedded) is more important
> than disabling an insecure cipher used by 33% of all TLS servers
> according to the most recent numbers.

Sarcasm? Will that help?

>> The reason the who-chairs thing reduces to perception is that
>> if that is not true, then our processes can be far more easily
>> undermined by anyone who has an axe to grind. And almost all
>> participants in standardisation do have some axe to grind. (I
>> think someone else pointed that out before as well.)
> 
> Some axes are better to grind than others. Heck, I'll be chair of
> CFRG. We'll hold a straw vote
> on the lines of my email on what kind of proofs are to be demanded
> from those who want us to
> bless a protocol first thing, and I will personally put $100 bond on
> any protocol we approve being broken,
> provided the protocol is standardized exactly as we say.

Honestly, I think taking up David's challenge to write the
draft(s) he mentioned would be a better way for someone new
to the RG to help out.

Your offering to chair seems meaningless to be honest.

>> The main effect of chairs is that they either move the discussion
>> along well, or badly, or not at all. The only situations where a
>> chair can really dominate are ones where nobody really cares about
>> the outcome anyway. And there are (in the IETF) appeal processes
>> in case someone thinks stuff has gone wrong. The IRTF differs in
>> that respect since the IRTF doesn't do standards.
> 
> How do I appeal against the continued failure of the TLS WG to fix the
> problems rediscovered
> this year? I know, I'll email the security area head telling them this
> is a problem.

More sarcasm. And combined with ignorance as to how the IETF works.
Sigh.

As I said above IETF area directors don't get to tell people what to
do. Participants are volunteers. For TLS, take your concerns to the
TLS list.

>>> To me, the most important thing the group can do is address how it
>>> makes sure to protect from subversive actors.
>>
>> I disagree, on the basis that I think we (IETF) have done that
>> for decades. More recently for IRTF, but it inherits a lot of
>> good IETF processes.
>>
>> For me, figuring out how to mitigate pervasive monitoring is
>> far more important.
> 
> Is this something that TLS doesn't solve? If it is too hard/expensive
> to deploy, that's yet another
> black mark against the history of the TLS WG. (Okay, UDP, but DNSCurve)

I've no idea what you mean. But we can probably pass on.

>>> If we had a clear
>>> answer there, then I think it matters far less who the chair is,
>>> because we can give outside eyes a better comfort level.  I don’t
>>> think it’s productive to be dismissive of the concern, even if you do
>>> not agree.
>>
>> It is fair to dismiss concerns where those appear to be based
>> on an impressive level of ignorance of how things actually work.
>> Those with such concerns should ask questions, and those would
>> be welcome, but baseless suppositions e.g. that some real people
>> are invented are just plain dumb.
> 
> If I look at the TLS WG I see 20 years of a broken, overly complex,
> protocol, with no effort being made to fix it.

No effort is nonsense. I think you mean you disagree with some
of what has been done and would like it all to be done faster.
Other than the blatant overstatement which doesn't help at all,
there are a lot of people who'd share that opinion. Making the
statement as you've done is however, counterproductive if your
goal is to improve the situation and not to grandstand.

> Whatever process was producing that result needs to be fixed. I agree
> imaginary people are an idiotic suggestion: the
> real record (pre-Dragonfly, pre-Snowden) shows that changes have to be
> made to the CFRG, the TLS WG, and probably to the way that the broader
> IETF views and understands cryptography.

I'll look forward to seeing how you help to make things better.

> 
>>
>> S.
>>
>> PS: I am not saying that all the how-stuff-works is very obvious
>> and ought be known, but I am saying that those who don't know,
>> should start by finding out before casting aspersions.
> 
> I'll start asking some questions: How many broken protocols does the TLS WG
> get to propose and have implemented as standards before it becomes
> a requirement for them to get some independent analysis of whatever
> they propose?

"Independent analysis" exposes your misunderstanding of the IETF.
*You* can do an analysis and write that up in an I-D. And see
Yoav's mail about the TLS renego bug and how many eyeballs missed
that (incl. mine of course). Its nice that you think everything
can be solved easily. Reality tends to disagree.

> How do you plan to deal with the failure of UTA to advance a necessary
> Best Practices document through the process in a timely
> manner?

That's nonsense. UTA has just been speedily chartered.

> 
> How do you propose to ensure that other working groups in the security
> area are not making similar misjudgements?
> 
> Does the IETF have any process to fix or address these issues?

I don't believe those are real queries, but just point-scoring
rhetoric. Do you think such rhetoric is helpful? Ask yourself
if it is or not.

And I would recommend that folks getting involved in the IETF or
IRTF do not start off by getting involved in process issues but
rather dive in to do technical work, writing or reviewing drafts.
(And I don't mean review-as-point-scoring, I mean review with a
goal of improving the outcome.) Its much easier to understand
the limits of process change after you've done some of the
technical work and far far too easy to spout well-meaning
rubbish about process change if you've not.

> Do you believe the CFRG has been effective in addressing the need for
> guidance on cryptography in the IETF?

Somewhat. I would like to see discussion of how to make it better
and more useful.

> Do you have any ways to improve that guidance or the process leading to it?

I'd love to see the RG discuss that and figure out what they think
is doable. I suggested some topics and others have added what look
like additional reasonable ones.

> 
> Is there any evidence the IETF can develop cryptographic protocols vs.
> having outside groups do it and present the standard to IETF?

Not sure what you mean. But there is IMO good evidence that the
IETF is best at standardising things that were initially done
outside the current WG setup. That maybe wasn't the case say
20+ years ago, and isn't really anything to do with security I
think. Giving IETF WGs a blank sheet from which to start does tend
to result in failure I think. But I'm sure other folks who have
participated might disagree with me on that. I wouldn't say there'd
be a rough consensus on the topic across the IETF nor the
security area.

I don't see how anyone who wasn't participating could offer a
useful opinion on that unless it was the topic of a master's
study or something (some brave souls have done that;-). But
some variation on your question is reasonable to ask, if its
directed towards trying to figure out how to improve our
processes and outputs.

Regards,
S.

PS: Whee-hee - last of many mails from me before the break:-)

> 
> Sincerely,
> Watson Ladd
>>
>>
>>
>>>
>>> John
>>>
>>>
>>> On Dec 23, 2013, at 9:15 PM, Tao Effect <[e-mail]>
>>> wrote:
>>>
>>>> On Dec 23, 2013, at 9:05 PM, Richard Barnes <[e-mail]> wrote:
>>>>
>>>>> Kevin is a regular IETF attendee, and an author of several RFCs.
>>>>>
>>>>
>>>> I never questioned that his name appears on several RFCs.
>>>>
>>>> I even linked to such an RFC. :-)
>>>>
>>>> It's just starting to become rather obvious that whoever is
>>>> carrying this name around, probably considers it to either be an
>>>> alias.
>>>>
>>>> And even if that's not the case, it seems rather strange that
>>>> someone who is serving as co-chair of an organization that makes
>>>> recommendations to the world about the cryptography that it uses,
>>>> appears to be rather difficult to hold accountable for the
>>>> accusations that have been levied against him by multiple people in
>>>> this thread.
>>>>
>>>> So, the members of the CFRG might not be real people and don't seem
>>>> to have any accountability? Is this the moral of the story?
>>>>
>>>> It's also interesting to see some of the replies to my innocent
>>>> questions.
>>>>
>>>> Here's one from Stephen Farrell, it can be summarized entirely like
>>>> so: "Oh FFS. Please cut the crap."
>>>>
>>>> Here's one from John Bradley: "+1 Stephen's comment"
>>>>
>>>> Some substance, gentlemen, please? This is not Facebook. It's easy
>>>> to disturb the air with exclamations, but it's not a nice thing to
>>>> do when your empty replies land hundreds? of inboxes.
>>>>
>>>> Cheers, Greg
>>>>
>>>> -- Please do not email me anything that you are not comfortable
>>>> also sharing with the NSA.
>>>>
>>>>>
>>>>> http://tools.ietf.org/googleresults?cx=011177064926444307064%3Arsqif7nmmi0&q=Igoe&sa=Search&cof=FORID%3A9&siteurl=tools.ietf.org%2Fhtml%2F&ref=&ss=3369j2532811j6
>>>>>
>>>>>
>>>>>
>> He is most definitely a real person.
>>>>>
>>>>> --Richard
>>>>
>>>> _______________________________________________ Cfrg mailing list
>>>> [e-mail] http://www.irtf.org/mailman/listinfo/cfrg
>>>
>>>
>>>
>>>
>>> _______________________________________________ Cfrg mailing list
>>> [e-mail] http://www.irtf.org/mailman/listinfo/cfrg
>>>
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> http://www.irtf.org/mailman/listinfo/cfrg
> 
> 
>