Subject: Re: [saag] Obligations of Candor

From: S Moonesamy <[email-masked]>
Date: Sun, 15 Jun 2014 08:46:09 -0700

Hi Watson,

[Thread moved to saag@ as requested]

At 06:25 15-06-2014, Watson Ladd wrote:
>I would like to see an addition to the IETF rules: participants must
>fully disclose security issues with the standard they are aware of, in
>all standards bodies they participate in, at the time of the Last Call
>for a standard. Such disclosure must be to all members of the
>committee developing the standard, and, in the event such a security
>issue remains post-ratification, public.
>
>This is motivated by the discovery that Certicom, in particular,
>patented a backdoor in Dual EC, and proceeded not to tell anyone. No
>doubt I have bumbled the above rule: but I would like to start
>discussion of what sort of rule we require to ensure that participants
>do not horde vulnerabilities, only to exploit them after the standard
>is ratified.

It is difficult to assess a specification which is being standardized 
when there is a lack of candor or when information which might 
potentially affect the decision is not publicly available.

There is the following text in a (IETF) RFC:

   "However, it is to be noted that there is an expectation that no one
    shall ever knowingly contribute advice or text that may adversely
    affect the security of the Internet without describing all known
    or foreseen risks and threats to potential implementers and users
    that they are aware of."

Regards,
S. Moonesamy

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 15 Jun 2014 12:48:07 -0700

>     or foreseen risks and threats to potential implementers and users

[BA] This (existing) advice is a lot more reasonable than Watson's proposal, although it too is obviously limited - it is the unforeseen risks and threats that often are the most problematic. This is particularly true in the privacy arena where a practice that might have been passed muster when it was first proposed (e.g.  use of long-lived MAC addresses in protocols) can be recognized as a privacy issue as the state of the art (e.g. MAC-based geolocation APIs) advances.

---

From: David Misell <[email-masked]>
Date: Sun, 15 Jun 2014 21:02:28 +0100

The following may be of interest:
http://ethics-wg.org/framework.html which bring together ISSA, ISC2 and SANS in it examined GIAC form.

As a member of all 3  I am signed up, but the ISC2 Ethical canons seem to hold up best when put under the spotlight.

https://www.isc2.org/ethics/default.aspx
Code of Ethics Preamble:   

    The safety and welfare of society and the common good, duty to our principals, and to each other, requires that we adhere, and be seen to adhere, to the highest ethical standards of behavior.
    Therefore, strict adherence to this Code is a condition of certification.

Code of Ethics Canons:   

    Protect society, the common good, necessary public trust and confidence, and the infrastructure.
    Act honorably, honestly, justly, responsibly, and legally.
    Provide diligent and competent service to principals.
    Advance and protect the profession.

Kind Regards

dave

On 15 Jun 2014, at 20:48, Bernard Aboba <[email-masked]> wrote:

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Watson Ladd <[email-masked]>
Date: Sun, 15 Jun 2014 17:19:57 -0300

On Sun, Jun 15, 2014 at 4:48 PM, Bernard Aboba
<[email-masked]> wrote:
> [BA] This (existing) advice is a lot more reasonable than Watson's proposal,
> although it too is obviously limited - it is the unforeseen risks and
> threats that often are the most problematic. This is particularly true in
> the privacy arena where a practice that might have been passed muster when
> it was first proposed (e.g.  use of long-lived MAC addresses in protocols)
> can be recognized as a privacy issue as the state of the art (e.g. MAC-based
> geolocation APIs) advances.

We're dealing with the situation where participants recognize a
security issue and fail to disclose it. Unrecognized issues are a
different
ball of wax: nothing short of careful analysis will work, and there is
always something missed such as RC4 in TLS.

This happened with an ANSI standard: Certicom recognized there was a
potential for a backdoor early on, but failed to publicise the issue.
When in 2007 it was independently recognized, products based on the
flawed standard were deployed.

Unforeseen risks will continue to be an issue, but by making clear an
expectation that you disclose what you know, we avoid a repeat of the
DUAL EC situation.

Sincerely,
Watson Ladd

---

From: S Moonesamy <[email-masked]>
Date: Mon, 16 Jun 2014 07:11:27 -0700

>expectation that you disclose what you know, we avoid a repeat of the

As background information, and to their credit [1], Tanja Lange and 
Watson Ladd publicly raised the issue on the (IRTF) CRFG mailing 
list.  I'll simplify the issue as: how not to repeat the DUAL EC 
problem.  The alternatives I could think of are:

   (i)   Not to reference ANSI publications in IETF standards

   (ii)  Not to reference CFRG publications in IETF standards

   (iii) Ignore the issue

The rationale for (i) and (ii) might be that the guidelines for 
companies participating in these bodies are not clear.

Regards,
S. Moonesamy

1. This is intended as positive

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Jun 2014 16:39:51 +0100

On 16/06/14 15:11, S Moonesamy wrote:
> Watson Ladd publicly raised the issue on the (IRTF) CRFG mailing list. 
> I'll simplify the issue as: how not to repeat the DUAL EC problem.  

Well, the IETF hasn't had a DUAL-EC problem really. We don't
afaik refer to that in any RFC that I can think of, at least
not directly. And when the various extended random proposals
were made those were not adopted thankfully. (Which could be
our process working well, or could be luck, I doubt we can
tell post-facto.)

> The
> alternatives I could think of are:

I'm not at all convinced those are a good set of options.
But I do have a comment on (ii).

>   (ii)  Not to reference CFRG publications in IETF standards

I'd be strongly against (ii). The IRTF operate the same IPR
rules as the IETF (by their choice) precisely so that we
can transition work from the IRTF to the IETF.

> companies participating in these bodies are not clear.

Anyway, you referred to RFC 7154 [1] before (and did so
nicely modestly:-). Isn't that plus the usual IPR rules
about as good as we can do really? Or do folks think
there's benefit in being more specific about security
or crypto or something there?

S.

[1] https://tools.ietf.org/html/rfc7154

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 16 Jun 2014 09:15:25 -0700

On Mon, Jun 16, 2014 at 8:39 AM, Stephen Farrell
<[email-masked]> wrote:
> were made those were not adopted thankfully.

Not true - see RFC 6358:

http://www.ietf.org/mail-archive/web/tls/current/msg11753.html

Trevor

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Jun 2014 17:47:40 +0100

> http://www.ietf.org/mail-archive/web/tls/current/msg11753.html

Ah, I guess yes you're right. Thanks for the correction.

Though there's no such extension defined I think, right? In which
case there's no actual harm done to the protocol, though perhaps a
bit of process harm maybe.

Does anyone have a use for 6358 or should we obsolete it or make
it historic?

S.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 16 Jun 2014 11:37:44 -0700

Hi Stephen,
>or crypto or something there?

I'll be candid.  It is very difficult to get IETF agreement on 
rules.  RFC 7154 is simply "please let's try this".  There are 
extensive notes about patents at 
https://projectbullrun.org/dual-ec/patent.html  It is up to the 
people responsible for IPR rules to see whether those rules are good 
enough.  I honestly don't know whether there is or has been a 
violation of those rules (in relation to the issue).  I'll leave the 
last question (quoted above) to readers of the mailing list.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Mon, 16 Jun 2014 22:54:03 -0700

Hi Stephen,
>Does anyone have a use for 6358 or should we obsolete it or make

Quoting Page 5 of http://dualec.org/DualECTLS.pdf

   "There are many extensions to TLS, but we draw attention to four particular
    proposed  but not standardized  extensions. Each of these extensions
    has the side effect of removing the most obvious difficulty in exploiting
    Dual EC in TLS, namely the limited amount of randomness broadcast to the
    attacker. One might guess that these extensions make P-256 less expensive
    to exploit in TLS by a factor of 65,536 (and make P-384 and P-521 feasible
    to exploit), if they are actually implemented; our analysis in Section 4.1
    shows that one of these extensions is in fact 
implemented in BSAFE, although
    the actual effect on exploitability is more complicated. None of these
    extensions have been previously described in connection with Dual EC."

For what it is worth ISO/IEC JTC 1/SC 27 
published an advisory note about one of its 
international standards.  There was a message 
about RFC 6358 to the TLS mailing list ( 
http://www.ietf.org/mail-archive/web/tls/current/msg11742.html ).

My short answer would be to move RFC 6358 to Historic.

Regards,
S. Moonesamy