Subject: Re: Last Call: Recognising RFC1984 as a BCP

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 10 Aug 2015 10:23:15 -0700

On 10 Aug 2015, at 10:13, The IESG wrote:

> The IESG has received a request from an individual participant to make
> the following status changes:
>
> - RFC1984 from Informational to Best Current Practice
>  (IAB and IESG Statement on Cryptographic Technology and the Internet)
>
> The supporting document for this request can be found here:
>
> https://datatracker.ietf.org/doc/status-change-rfc1984-to-best-current-practice/

Yes, please. What was discussed in 1996 really is a best practice today, 
and it has certainly been made the current practice.

--Paul Hoffman

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 10 Aug 2015 10:34:00 -0700

> On Aug 10, 2015, at 10:23 AM, Paul Hoffman <[email-masked]> wrote:
> 
> Yes, please. What was discussed in 1996 really is a best practice today, and it has certainly been made the current practice.
> 
> --Paul Hoffman

Umm, the document is specifically worded as a position statement from the
IAB and IESG.  There is no "current practice" described by it.  Rather, it is an
argument against key escrow and limited key sizes; a sort of anti-pattern for
an old practice.

I'd rather it be left as an informational document, as it was approved, and
a new BCP be produced that explains current best practices regarding minimum
key sizes, currently-safe algorithms, etc.  Something that isn't tied to a
specific protocol (unlike TLS 1.3).

....Roy

---

From: Eliot Lear <[email-masked]>
Date: Mon, 10 Aug 2015 20:42:40 +0200

Hi,

On the whole I support RFC 1984 as already being a well established best
current practice.  Before we elevate the document, I would ask this
simple question: what purpose is intended in doing so?  If the purpose
is to inform policy makers  that breaking encryption in some way either
through key escrow, export (or import) limitations, or limiting key
length is a bad idea, then upgrading 1984 to a BCP really the wrong
mechanism.   Upgrading something from informational to BCP may have some
meaning *to us*, but generally not to others.

To me a better approach may be for the IESG and IAB to issue another
joint statement that recognizes the value of RFC 1984 and makes clear
that the key ideas put forth then are still correct now, while at the
same time addressing some concerns that are really on the minds of some
policy makers.[*]  Applying the principles from 1996 in today's world
would be more helpful, IMHO, in the public arena.  Just changing the
label in rfc-index.txt doesn't on its own accomplish that.

Which brings me to a final point.  Somewhere in this process, someone
(preferably either a shepherding AD or the person requesting the change)
can surely articulate the reasoning for this change.  I'm actually not
aware of any other informational document being upgraded to BCP, so I
don't know what has been done in the past or what process was used, but
I was surprised that this wasn't in a write-up somewhere when the LC
announcement issued.

Eliot

[*] Those who know me know that I am not enthralled with what I call
naked IAB or IESG statements along these lines.  Usually I like an
analysis to go with in the form of an RFC.  In this case, however, that
RFC would be 1984.

On 8/10/15 7:13 PM, The IESG wrote:
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2015-09-07. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> The affected document can be obtained via
> https://datatracker.ietf.org/doc/rfc1984/
>
> IESG discussion of this request can be tracked via
> https://datatracker.ietf.org/doc/status-change-rfc1984-to-best-current-practice/ballot/
>
>
>

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Aug 2015 13:18:19 -0700

> https://datatracker.ietf.org/doc/status-change-rfc1984-to-best-current-practice/

This document pertains to an especially important and difficult topic.
If IETF approval of such a document is to have the utility we expect for
it, we need to be clear about that intended effect, clear how the
document addresses it, and clear about its robustness against
misinterpretation or dismissal by those needing to attend to the
document but disinclined to do so or actively interested in undermining it.

The supporting document asserts consensus within the ad-hoc saag group
has a number of basic problems.  So the document is an individual
submission but relies on purported group rough consensus that was never
established.

First, saag is an accidental group that had no specific, documented task
for considering this draft.  As such, some who might have wished to
participate in thoughtful discussion of this topic had no way to know
about it.

Second, discussion on the list was entirely ad hoc, with no convergence
and (rough) consensus processes.  The only consensus-related process
concerning this document was during the saag session during the IETF
meeting in Prague.  There was no followup on the saag mailing list or
any other.  Hence the supporting document's second paragraph's reasons
for rejecting an effort to revise the document have no documentable
foundation.

As an example of the randomness of the mailing list discussions, points
I raised about the reasons a revised document is needed to respond to
the current pervasive monitoring concerns received no substantive
responses.

Making a carefully-considered (rough) consensus choice against concerns
is one thing.  Ignoring them completely is quite another.

The relevant portions of my posting to the saag list:

-------- Forwarded Message --------
Subject: Re: [saag] keys under doormats: is our doormat ok?
Date: Mon, 13 Jul 2015 12:38:09 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: [email-masked] <[email-masked]>

On 7/12/2015 5:23 PM, Christian Huitema wrote:
>> So I suggest that one of the plenaries contain a capsule summary
>> -- bulleted list -- of the points folk think should be made in the
>> revision, and that a 'sense ofthe room' be taken during the
>> plenary.
> General agreement, but I would rather not call this a revision.
> Maybe something like "reaffirm."

It's more than reaffirm. Possibly quite a bit more.

The existing document has a very strong focus on export control
and sharing of keys. The current issue is backdoors, and the like.
While the existing document does list the need for private keys to be
private, it's not really dealt with in the surrounding text. Changing
that would be a substantive, compatible addition to the existing document.

Also the existing document does not contain an explicit and affirmative
statement of the basic, high-level requirements on a security mechanism.

The closest it comes to a statement of principle in the document is:

     Security mechanisms being developed in the Internet Engineering
     Task Force to meet these needs require and depend on the
     international use of adequate cryptographic technology.

The sentence after that applies the above to the particulars that the
document addresses:

     Ready access to such technology is therefore a key factor in the
     future growth of the Internet as a motor for international
     commerce and communication.

"Access" was the issue of the day. Today's issue is not the same,
though of course it is firmly attached to the first of the above statements.

In effect, the document could benefit from discussion at a higher level
and at a lower level. The higher level is a more complete statement of
the purpose, benefit and necessity of effective communication privacy,
and clarity about what that benefit means to users.

At the lower level, the document could benefit from some pragmatics,
along the lines of what Stephen has suggested: What should a working
group dealing with this realm of technology do and not do?

When we approve something purporting to provide a component of
'security', what basic expectations of that mechanism or system should
its consumers expect from it? To put it a bit grandly, what is the
'philosophy' of security that the IETF is applying?

For example, I believe the current issue hinges on an IETF belief that
those who choose to do encryption should be able to control who is
authorized and able to do the decryption.

Also there has been quite a bit of public discussion, this time around,
and the document should reflect on that activity.

...

In sum, I think the revised document should:

0. Establish the current context including examples of related public
contributions. One recent publication would be obvious to include...

1. Provide statements of IETF principles about the nature and
requirements for privacy-related technologies, explicitly citing
relevant examples that would violate this.

2. Explain every 'what' with a 'why'. For each thing claimed to be good
or bad, explain the implications of ignoring the claim.

3. Give guidance that IETF efforts can use in designing new mechanisms,
formats, etc.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 10 Aug 2015 22:26:15 +0200

Speaking from my own experience of a similar document:

At the time of issuing RFC 2804, "IETF Policy on Wiretapping" (which is
also Informational), the thinking of the IESG and IAB was that the IESG
and IAB (a finite set of individuals) were able to make a strong
statement that "we have consensus on this position", while attempting to
make a BCP (which implies that the IETF community has consensus on the
position) was much more difficult - there would always be SOME people
who would not want to be counted as part of the consensus, and others
who would argue that some other people (who were not part of the debate)
would disagree, and would therefore invalidate the idea of there being a
consensus. (I think the logic of this argument is suspect, but that's
another matter.)

The thinking then was that we should issue an Informational because we
could do that in a timely fashion, but wouldn't be able to get a BCP in
a timely fashion.

The times may be different. We may have established a smooth IETF
consensus on RFC 1984 over the intervening years, and BCP would just be
an acknowledgement of that status.

I am willing to be counted as part of the consensus for RFC 1984 as a BCP.

Harald

---

From: Eliot Lear <[email-masked]>
Date: Mon, 10 Aug 2015 23:29:52 +0200

Updating what I wrote:

> I was surprised that this wasn't in a write-up somewhere when the LC
Sorry- I missed the write-up the first time.  The question I would still
like clearly answered is the one that Dave Crocker asked.  What is the
intended effect?

Thanks,

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Aug 2015 10:06:33 +1200

On 11/08/2015 05:34, Roy T. Fielding wrote:
> I'd rather it be left as an informational document, as it was approved,

When RFC 1984 was published, the way BCP was defined by RFC 1818 made it impossible
to classify it as BCP. RFC 2026 expanded the definition of BCP considerably
and specifically mentioned "the results of community deliberations" and
"common guidelines for policies" and is explicit that a BCP can be a vehicle
for IAB and IESG statements subjected to community consensus. So we are a
few years late, but this action seems well within the rules.

> and

That sounds like a fine thing to do, but it's orthogonal to underlining
that the principles in RFC 1984 apply even more strongly today.

     Brian

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 Aug 2015 07:26:55 +0900

> I am willing to be counted as part of the consensus for RFC 1984 as a

i too

maybe s/willing/enthusiastic/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 10 Aug 2015 15:53:25 -0700

> On Aug 10, 2015, at 3:06 PM, Brian E Carpenter <[email-masked]> wrote:
> 

That doesn't change the content of the text, which is not expressing a BCP
in any shape or form.  It is an opinion piece, which is fine as Informational.
The document does not describe common guidelines for policies, nor does it summarize
the results of community deliberations.  It states an opinion of the IAB and IESG
at that time regarding two very bad suggestions for key management.  The right
opinion, IMO, but still just an opinion of a dozen or so individuals.

Changing the document status serves no useful purpose.  At best, it provides a
bad example of how to write other BCPs.  If you can't generate enough energy
to re-edit the document as a consensus specification, then it surely isn't
important enough to serve as a bad example of back-door standardization.

Why is it that security-related statements by the IESG need to avoid
being subject to the same process as all our other specifications?

....Roy

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Aug 2015 16:18:51 -0400

Roy T. Fielding <[email-masked]> wrote:
    > Umm, the document is specifically worded as a position statement from
    > the IAB and IESG.  There is no "current practice" described by it.
    > Rather, it is an argument against key escrow and limited key sizes; a
    > sort of anti-pattern for an old practice.

1) I think that the goal here is that RFC1984 permitted WG to
   make things like KEY ESCROW, weaker keys, etc. as out of scope.
   But 1984 didn't actually say that; it just provided the background
   by which to argue (or rather, conclude the argument quickly) the point.
   So I agree with the letter of Roy's argument.

2) I think that the BCP that we are trying to describe is that
   the IETF doesn't design back doors into protocols.

   I agree that RFC1984 doesn't actually say that.

Having said this, I support an effort to re-inforce or re-recognize 1984
as still relevant.  If marking it as BCP, and therefore giving it a BCP#
makes sense, I'm for it.  As BCP# can refer to multiple documents, we could
then write a short BCP that captures point (1) above, and it could be added.
I don't want to re-open 1984... we'll wind up boiling an ocean.

    > and a new BCP be produced that explains current best practices
    > regarding minimum key sizes, currently-safe algorithms, etc.  Something
    > that isn't tied to a specific protocol (unlike TLS 1.3).

Such a document has been produced by the IPsec(ME) WG on an irregular
basis. For instance: http://datatracker.ietf.org/doc/rfc7321/
which obsoleted http://datatracker.ietf.org/doc/rfc4835/

And really, one must do this on a (security) protocol-by-protocol basis.
I think that TLS has updated this in the main protocol document.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Aug 2015 16:17:36 +1200

Roy,

> opinion, IMO, but still just an opinion of a dozen or so individuals.

That isn't so. Trivially, it was more like two dozen people (IAB+IESG)
speaking as bodies put in place by the IETF community, not as individuals.
Non-trivially, we strongly believed at the the time that we were giving
the rough consensus view of the IETF as a whole. There was a vigorous
debate in plenary at IETF 32 (Danvers, April 1995) which made the strength
of opinion in the IETF about the need for strong crypto very clear.
Unfortunately I can't readily find any trace of minutes of that plenary.

The first draft of what became RFC 1984 was circulated and wordsmithed
within the IAB and IESG, starting June 1996. An IAB and IESG Statement
version was released to the media on July 24, 1996 and simultaneously
sent to the IETF list, with a statement of intent to publish it as
an RFC. There was a rush due to US Congressional hearings that week.

The only comments we got on the IETF list were supportive, although
there was no formal last call. The RFC version was posted August 19,
1996.

> to re-edit the document as a consensus specification, 

The whole point is *symbolic*. What we (the IETF) thought in 1995/96
is what we think now, and the choice of RFC number was not accidental.
Promoting it to BCP, consistently with RFC 2026 as I pointed out
before, reinforces that nothing in the last 20 years has changed
the underlying logic.

Yes, if the RFC 2026 definition of BCP had been in force in July 1996,
we'd have worded it slightly differently and there would have been
a formal Last Call. But it wasn't, so we didn't.

   Brian

> then it surely isn't

---

From: Eliot Lear <[email-masked]>
Date: Tue, 11 Aug 2015 08:22:44 +0200

Hi,

On 8/11/15 6:17 AM, Brian E Carpenter wrote:
>
>     It states an opinion of the IAB and IESG

While I wasn't in leadership, this matches my recollection at the time. 
Had the IAB or IESG called for comment, I'm sure they would have gotten
enthusiastic support from the community, which at the time was
galvanized against both export restrictions and the use of key escrow
(keep in mind this was probably the peak of key signing parties at the
IETF). 

I think if we reopened 1984 today we'd probably include discussion of
the need for PFS and might even venture to provide references to high
profile examples of some governments' inability to secure THEIR secure
information, much less that of others.  On balance, though, the document
stands the test of time.

Eliot

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 11 Aug 2015 03:26:14 -0700

> I am willing to be counted as part of the consensus for RFC 1984 as a BCP.

+1

-- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
[email-masked]
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Aug 2015 12:52:23 +0100

Hiya,

Responding to a few things at once:

On 10/08/15 22:29, Eliot Lear wrote:
> The question I would still

This may have already been answered sufficiently well by Brian, but
in addition to what he said I think that this status change is just
recognising reality as we do treat RFC1984 as a BCP. And formally
recognising that could also avoid us having to deal with arguments
about RFC status or the age of the RFC should someone start to argue
afresh for the IETF to e.g. support mandatory key escrow. (I'm not
aware that we're about to see any such argument btw so that last is
more insurance than anything.)

On 10/08/15 23:53, Roy T. Fielding wrote:
> That doesn't change the content of the text, which is not expressing
> a BCP in any shape or form.

RFC1984 says:

  "Security mechanisms being developed in the Internet Engineering Task
   Force to meet these needs require and depend on the international use
   of adequate cryptographic technology."

I read that use of "require... adequate" (and the rest of the text) as
defining a class of crypto that we do not accept for use with IETF
protocols so I think there is real BCP here even if there are no MUST
statements.

> submission but relies on purported group rough consensus that was never

The supporting document says:

"Based on the the saag list discussion and questions considered at the
saag meeting at IETF93, the security area of the IETF appears to have
rough consensus to change the status of RFC1984 to BCP in-place,
without changes to the text."

The "appears to" is important there. As you point out, we don't have
a formal way to establish rough consensus via saag so this IETF LC
is what matters. I certainly was not trying to pretend (nor "purport")
that we have a better grasp of consensus than is the case. OTOH, we
also have nearly 20 years of happily using the RFC as if it were a
BCP and I do think that counts too.

> participate in thoughtful discussion of this topic had no way to know

Using an area mailing list like saag as the venue for early discussion
here is entirely appropriate.

> any other.  

Wrong. I posted twice to the saag list since Prague saying that
this IETF LC was the plan. There was no objection.

> Hence the supporting document's second paragraph's reasons

See the earlier mail thread. And at the Prague IETF session there
was a (to me) clear consensus to not re-open the document for edits.

> is one thing.  Ignoring them completely is quite another.

I think the mail thread on saag, and the meeting room in Prague
showed a clear consensus to not re-open this document for edits.
(Some of the mails to that effect preceeded yours.) But this LC
will tell if I'm right or wrong there.

> 3. Give guidance that IETF efforts can use in designing new mechanisms,

Yes, doing the above would certainly have merit but more as part of
an exercise to revise BCP72, especially your #3 above which would
also require a very significant level of effort. (If there's more
folks interested in working on those topics I'd be happy to try help
regardless of whether that's seen as revising BCP72 or as being
better handled some other way.) In any case your list seems to me
clearly separable from this status change.

Cheers,
S.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 11 Aug 2015 08:23:49 -0400 (EDT)

> I don't want to re-open 1984... we'll wind up boiling an ocean.

I agree. I think it is important that we re-inforce RFC 1984. So I am in
favour of turning the existing document into a BCP.

> I think that TLS has updated this in the main protocol document.

But such documents are very hard to write. Even within the IPsec
community, the various updates on which crypto related options to
obsolete and which to recommend end up in a very strange combination of
consensus. I would actually prefer to see a stand-alone document that
tries to extract all the cross-protocol crypto options into one set of
recommendations, so that these are not ending up with different
consensus calls within different working groups. For example, we should
have a crypto recommendation about SHA1, HMAC-SHA1 and even things like
PFS and only leave protocol specific things (eg AH vs ESP-NULL) into the
respective working groups.

Paul

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 10 Aug 2015 15:02:01 -0400

>     (IAB and IESG Statement on Cryptographic Technology and the

I support this status change.  The text of RFC 1984 holds up well and is
(unfortunately) still quite relevant to the privacy and security
concerns of people using the Internet today.

Regards,

      --dkg

---

From: Eliot Lear <[email-masked]>
Date: Tue, 11 Aug 2015 17:28:36 +0200

> more insurance than anything.)

Ok.  Thanks.  To be clear, I have no serious concern with 1984 being
upgraded.  As I wrote, the text has stood the test of time quite well.

Eliot

---

From: Bob Hinden <[email-masked]>
Date: Tue, 11 Aug 2015 08:43:48 -0700

Hi,

After reading the email thread my questions have been answered, and I support moving RFC1984 to BCP.

Bob

---

From: Sam Hartman <[email-masked]>
Date: Tue, 11 Aug 2015 12:14:34 -0400

After re-reading RFc 1984, I support its reclassification as a BCP.
The text holds up surprisingly well.
There were a couple of moments where I found myself laughing,
particularly at how little boiler plate RFCs had back then, and one or
two in the text, but overall it's quite good and the arguments still
apply.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Aug 2015 12:56:24 -0400

I would propose that the new BCP be the set of 1984 and RFC2804 (which is
also informational).
I also think that this would be proceedurally make more sense.

---

From: John C Klensin <[email-masked]>
Date: Tue, 11 Aug 2015 14:04:22 -0400

--On Tuesday, August 11, 2015 16:17 +1200 Brian E Carpenter
<[email-masked]> wrote:

>...
> The whole point is *symbolic*. What we (the IETF) thought in
> 1995/96 is what we think now, and the choice of RFC number was
> not accidental. Promoting it to BCP, consistently with RFC
> 2026 as I pointed out before, reinforces that nothing in the
> last 20 years has changed the underlying logic.

Sure.  I don't think you will find many people who will disagree
with that and I certainly won't be one of them.  If anything the
problem has gotten more complex and more important.

Parts of what is said below have been raised by others.  I'm
writing this note because I may be able to contribute a slightly
different take on it.

However, for symbolic acts, I think it is important to be clear
about what we are trying to accomplish and how (or if) a
particular move will help with that.  As part of that, we
should, at least IMO, be clear in our own minds that the
symbolism is a political/sociological move and far less an
engineering one.  In that regard, most of 1984 sticks fairly
close to the engineering.  For example "key escrow is a bad idea
because it creates extra security holes" (a reasonable, but not
exact paraphrase) is, in large part, a component of a technical
vunerability assessment rather than exclusively a
political-symbolic one.

If we want to make political statements, the various chess game
analogies apply: it it important to figure out and be explicit
about (at least internally), not only what our goal is but who
the audience is and how various parts of it are likely to
respond.   We also, I believe, need to be as explicit about
goals and intentions as possible lest we effectively leave it up
to others to interpret things in their own way.

That leads me to a few conclusions, fwiw....

(1) If the goal of reclassifying this to a BCP is simply to
guide IETF protocol development, I don't think that is
necessary.  We haven't had a proposed standards track spec in
more years than I can remember that advocates any of the things
that RFC 1984 argues against.  As far as I know, we haven't even
had an independent submission to the RFC Editor advocating such
things.  I believe that such a proposal would get very harsh
treatment and that anyone who would be inclined to seriously
initiate either effort knows that (or would find our with
remarkable swiftness).  In that sense, RFC 1984 is part of the
IETF culture.  Making it a BCP won't make it more so or create a
stronger bar in practice to the work it discourages.
Reclassification may have some symbolic impact outside the IETF
community and its work, but that is a different objective.

(2) If our goal is to make a sociopolitical statement, e.g., by
calling additional attention to the statements in RFC 1984, it
is the worst possible example of justifying a change and calling
attention to it by making a note in the datatracker.  We'd be
far better off doing even a rudimentary retrospective (most of
the needed thoughts are already in the tracker justification),
including an explanation of the move and/or what we expect to
accomplish, publishing it in the RFC Series, changing the status
of 1984 as part of its approval process, and then giving both
the new document and 1984 the same BCP number.

(3) Finally, there is the goal question of who we expect to
influence and what the effects might be.  It is probably a mark
of 1984's success that it is common knowledge and generally
accepted around the IETF, so changing its status is unlikely to
contribute to our knowledge.  If the hope is to influence
governments who are nervous about strong encryption and/or
believe they have the right and maybe even the obligation to spy
on traffic within and across their countries, the odds of our
having a significant positive are, I believe, fairly low.  Think
about a legislator standing up in West Snoopovia and saying "the
IETF says we should stop worrying about snooping and encourage
individuals to use encryption strong enough that we can't break
it" and how much influence such a statement is likely to have.
if we could say confidently that our pushing 1984 in the
political sphere might be beneficial in some places and would
otherwise have no ill effects, it would clearly be worth doing
anyway.  But suppose the hypothetical government of West
Snoopovia responds by considering the reclassification and
associated publicity to be an attack on them and their policies
(whether that was actually correct or not).  That would not
improve the lot of their citizens.  It might provide the
incentive (or at least the excuse) for even more restrictive
policies, aggressive surveillance, or even cutting more of their
population off from the Internet -- policies exactly counter to
our presumed desires unless we think that making things worse is
the precondition for improvement or even revolution.  The
situation would also give them some additional excuse for
standing up in various international forums and making the claim
that, since the IETF is obviously a puppet of powers and
policies hostile to them and the independence of national
policies, the only acceptable outcome is to more Internet
standards work to some appropriate international body or treaty
organization in which they have a voice rather than having
things rigged against them.  Whether that effort succeeded or
not, we probably don't need more countries subscribing to it as
a policy or having what seem to them and like-minded countries
like proof that the IETF is the wrong solution going forward.

We really don't need that, nor do the citizens of  West
Snoopovia need us to make a statement whose effect, in their
hands, is to make an already bad situation worse.

So the question that comes directly after "what are we trying to
accomplish?" is "given that it might have costs, are they worth
it?"  I'm 
having a lot of trouble getting to an unambiguously positive
answer.

best,
    john

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Aug 2015 19:17:14 +0100

Hiya,

> I also think that this would be proceedurally make more sense.

I did ponder that a bit but my own conclusion fwiw was that the
topics are sufficiently different that keeping them separate could
be better and would be simpler. And if we wanted 2804 as a BCP that
could be done after we see what folks think of this status-change. I
do agree that it'd be sensible to consider following the same path
with both of these at some point, though I'd say it's maybe simpler
to take 'em one at a time.

S.

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Aug 2015 11:20:34 -0700

> I also think that this would be proceedurally make more sense.

Has anyone considered the potential to revise this document properly (as
it should be) and then issue it (and any additional documents) as "BCP
1984"?

If kitsch is what you're after, that would serve the purpose without
this silly end-run around process.

Joe

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 11 Aug 2015 14:29:54 -0400

I'm a little late responding...

Sent from my iPhone

> On Aug 11, 2015, at 7:52 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

I agree that this consensus was clear in the meeting and is now being discussed on lists following the usual process.

Thanks,
Kathleen

---

From: Sam Hartman <[email-masked]>
Date: Tue, 11 Aug 2015 14:45:58 -0400

>>>>> "Joe" == Joe Touch <[email-masked]> writes:

    Joe> On 8/11/2015 9:56 AM, Michael Richardson wrote:
    >> 
    >> I would propose that the new BCP be the set of 1984 and RFC2804
    >> (which is also informational).  I also think that this would be
    >> proceedurally make more sense.
    >> 
    >> -- Michael Richardson <[email-masked]>, Sandelman Software
    >> Works -= IPv6 IoT consulting =-

    Joe> Has anyone considered the potential to revise this document
    Joe> properly (as it should be) and then issue it (and any
    Joe> additional documents) as "BCP 1984"?

That idea has definitely been brought up.
However,  for myself, I find that I much prefer promoting the existing
RFC to BCP.

I think we'd tend to have a significant fight about what belongs in a
BCP and what doesn't.
I don't tend to agree with your comments that:

1) A BCP needs to be recommendations to protocol designers/operators; I
read RFC 2026 differently and believe we can use a BCP as a tool for
making any consensus recommendation we feel appropriate.

2) I don't think the issues surrounding whether we're issuing a new
document here are any different than any reclassification.  I often find
when a standard is proposed for advancement that I wish it would change
some.  We've decided that moving things forward is valuable enough that
you need to be able to get enough people to want to make changes in the
last call to open up the document before you can force that.

3) I disagree with your desire to remove some of the political
statements from the document.  In this instance, I think we actually
have consensus strong enough that it's worth the IETF making those
statements.

So, for myself, I favor the current process because I believe it is an
efficient mechanism for getting a stronger document approved.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Aug 2015 11:52:47 -0700

> I agree that this consensus was clear in the meeting and is now being discussed on lists following the usual process.

Kathleen,

Forgive me, but no.  A very big no.

An IETF "Last Call" is not the usual process for discussion.  Last Call
is intended for /after/ such discussion.

Again:  there has been no managed discussion and no serious effort to
pursue basic concerns that have been raised.

Mostly, basic concerns are simply being ignored or quickly rejected.

d/

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Aug 2015 13:09:48 -0700

> I think we'd tend to have a significant fight about what belongs in a

I would encourage you to respond to the rest of my post, where I
provided a long list of very specific issues that I disagree with.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Aug 2015 09:03:43 +1200

>> I also think that this would be proceedurally make more sense.

My recollection is that the 1995/96 debate that led to RFC 1984
was virtually unanimous, but the consensus for RFC 2804 was quite
a bit rougher.

> this silly end-run around process.

There is no end-run. The IESG might conclude from the discussion that there
is no rough consensus to reclassify the RFC.

In which case, yes, developing "BCP 1984" would be a cute response. But that would
be a separate discussion.

   Brian

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Aug 2015 14:06:33 -0700

> is no rough consensus to reclassify the RFC.

IMO, reclassifying an existing RFC that isn't to "Historic" is an end-run.

Joe

---

From: "Scott O. Bradner" <[email-masked]>
Date: Tue, 11 Aug 2015 17:10:10 -0400

there was discussion & revisions in both cases but I agree that there were more in the case of 2804

Scott

> On Aug 11, 2015, at 5:03 PM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: "Scott O. Bradner" <[email-masked]>
Date: Tue, 11 Aug 2015 17:13:52 -0400

I disagree with this as an absolute statement

there are times, not all that often but actual cases, where a technical RFC has been progressed
on the standards track without creating a new RFC

it does take developing information about implementations etc, bit that info does not go into a RFC

Scott

> On Aug 11, 2015, at 5:06 PM, Joe Touch <[email-masked]> wrote:
> 
> 
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Aug 2015 14:17:38 -0700

OK, so basically changes in the standards track:

	promotion
	demotion (e.g., to Historic)

I can even see changing informational de-facto or individual standards
to standards-track.

What makes NO sense is a BCP. If it wasn't a BCP when it was issued
(even if there was no such thing), then it isn't a BCP now.

If you want a BCP now, then open the can of worms and have the
discussion on content.

This whole thing, however, is based on the ridiculous goal of retaining
an RFC number - numbers that we NEVER assume we can retain for even the
most ubiquitous of standards.

Joe

---

From: Pete Resnick <[email-masked]>
Date: Tue, 11 Aug 2015 16:18:42 -0500

On 11 Aug 2015, at 6:52, Stephen Farrell wrote:

>> What is the intended effect?
>

Changing the status seems to fill a well-needed gap, and I suspect that 
it’s just a rationalization to be able to make the political 
statement. If someone should argue in the future for the IETF to support 
nastiness, that’s the time to confirm that we have consensus not to do 
that, and to write that down in the form of an IETF BCP. In other words, 
I don’t buy this as a justification.

> protocols so I think there is real BCP here even if there are no MUST

Read that in context. This is part of the fluff in the intro, not a 
directive. True and good fluff, mind you, but not a BCP statement.

1984 is written from top to bottom as the opinion of the IAB and IESG, 
not a BCP. Had I known then what I know now, I might have objected to 
the IESG signing on to the statement (because the IESG should only be 
making consensus statements for the IETF, IMO). But it was a different 
time, and I’m OK with that.

If you really think the IETF needs to make a consensus statement on this 
topic (and see above for why I’m not convinced of the necessity), 
write a new intro which says, “Recent questions caused the IETF to 
revisit the ideas in RFC 1984. The main points of 1984 are no longer 
just IAB and IESG opinion. The IETF has consensus for these principles, 
and they guide how we write our documents.” Include (without the 
“this is just an opinion” qualifying text) what’s in 1984. Publish 
to the IETF list. After some discussion, Last Call. Done. Easy.

If it’s not easy, routing around the damage of the IETF by trying to 
use the status change mechanism to “sneak it in” is just worsening 
our state of horror.

> without changes to the text."

Bogon alert! I don’t give a rodent’s rear that any group of IETF 
humans (other than the IESG) has a rough consensus to make any document 
any particular status. If that was the consensus question being asked on 
saag, it was a bad one. We come to consensus on technical content. If 
saag had consensus on some technical points, write those down and 
propose it as a BCP.

You haven’t (IMO) sufficiently addressed the objections to the status 
change. Either leave “good-enough” alone and let this remain as it 
is, or write a proper BCP version and Last Call that.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Aug 2015 18:40:28 -0500

> I also think that this would be proceedurally make more sense.

I agree, this does make much more sense.

Nico
--

---

From: IAB Chair <[email-masked]>
Date: Wed, 12 Aug 2015 13:39:27 -0400

Dear colleagues,

The IESG asked for community consent to advance RFC 1984 from
"Informational" status to "Best Current Practice" in their IETF last
call of 2015-08-10.  As an author of RFC 1984, the IAB supports the
change.

Best regards,

Andrew Sullivan
For the IAB

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 12 Aug 2015 18:25:05 +0000

> On Aug 12, 2015, at 10:39 AM, IAB Chair <[email-masked]> wrote:
> 
> Dear colleagues,
> 

I am mentioned in the RFC as the IETF Chair and a member of the IAB at the time of the writing of RFC 1984, and one of the co-authors.

I support the advancement.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 12 Aug 2015 13:21:32 -0700

> On Aug 10, 2015, at 9:17 PM, Brian E Carpenter <[email-masked]> wrote:

Sorry, I don't consider the IAB and the IESG to be bodies put in place
to write opinion pieces.  I consider them to be a dozen or so individuals
who have a specific role to play in the IETF process (and yes, a dozen or so
includes two dozen).  I pay attention to their decisions only when they are
relevant to their IETF roles, even when I agree with those decisions.

> Unfortunately I can't readily find any trace of minutes of that plenary.

I was there.

> there was no formal last call. The RFC version was posted August 19,

I think you completely missed my point.  The document says it is an
opinion piece by the IAB and IESG.  Everything in it is phrased as such
to avoid pissing off the people in the IETF who believe the institution
should not be playing politics.  The result is fine in the context
of an informational RFC.  It is not fine for a BCP, even if that document
is brought to the IESG with full consensus of all working groups.

> a formal Last Call. But it wasn't, so we didn't.

So, word it differently now, hold a last call on the different text,
and publish it as a proper BCP.  I have revised HTTP three times in the
same period, all according to the process, because I respected that the
result would be better than if I had not.

BTW, I think the choice of 1984 as an RFC number was atypically juvenile.
I don't think anyone outside the echo-chamber has taken RFC1984 seriously,
regardless of its status; instead, the opinions it described have been
adopted because the alternatives it argues against are inherently stupid.

....Roy

---

From: Eliot Lear <[email-masked]>
Date: Wed, 12 Aug 2015 22:55:33 +0200

Hi,

On 8/12/15 10:21 PM, Roy T. Fielding wrote:

> to avoid pissing off the people in the IETF who believe the
> institution should not be playing politics. The result is fine in the
> context of an informational RFC. It is not fine for a BCP, even if
> that document is brought to the IESG with full consensus of all
> working groups. 

This is not simply politics, although we cannot deny that there are
some.  But to put it only in those terms demonstrates a misunderstanding
of RFC 1984.  The document represents what was and is, I believe, a
strong consensus view that key escrow, key length limitations, and
export restrictions are technically harmful to Internet users for all
the reasons stated in the draft.  The points made in the draft were
technically indisputable then and are indisputable now.  If we had to
open up 1984 we simply wouldn't change much, but we *would* make it a
BCP.  So why not just do so?

> BTW, I think the choice of 1984 as an RFC number was atypically
> juvenile. I don't think anyone outside the echo-chamber has taken
> RFC1984 seriously, regardless of its status; instead, the opinions it
> described have been adopted because the alternatives it argues against
> are inherently stupid. ....Roy 

That didn't stop governments from imposing export restrictions or
proposing key escrow and other bad ideas.  That we are here again now is
disheartening.

 But I'll say one more thing about this: there is, I think, value in
delving into the substance of the law enforcement is raising.  Today
there was an editorial by Cyrus Vance, Jr. amongst others in the New
York Times that called out Apple and Google on their approach.[1]  Last
week there was an article in that same paper about how wiretapping
brought down a huge scam at Brazilian oil producer Petrobras.[2] 
Applying the sound logic of 1984 to these new examples probably would be
very helpful.  In addition, there have been massive security failures
involving escrowed keys.  Highlighting that would also be helpful.  All
of these points would emphasize just how timeless RFC 1984 truly is, and
so should be recognized as a BCP.  Doing so may also facilitate a very
much needed dialog between law enforcement and the technical community.

As to any process issues, we have the ability as a community to make
exceptions, if we believe a process exception is needed.  Rough
consensus gives us that freedom.

Eliot

[1]
http://www.nytimes.com/2015/08/12/opinion/apple-google-when-phone-encryption-blocks-justice.html
[2]
http://www.nytimes.com/2015/08/09/business/international/effects-of-petrobras-scandal-leave-brazilians-lamenting-a-lost-dream.html

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 12 Aug 2015 14:02:48 -0700

> On Aug 11, 2015, at 4:52 AM, Stephen Farrell <[email-masked]> wrote:

That's a great example of selectively misreading a poorly written text
that would not have passed through a normal last call period, let alone
the IESG review, if it were not for the fact that everyone was reviewing
it as an opinion piece instead of a formal spec.

I read it as "That international commercialization of the Internet stuff
we are doing is based on the premise of strong cryptography being generally
available to provide confidentiality both within and across national borders."

The reason I read it that way is because, in fact, none of the protocols
we developed at that time actually required strong cryptography.  They
just assumed you would layer the right amount of cryptography underneath,
using one of the (at that time) non-IETF security protocols with appropriate
patent and export licensing.

....Roy

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Aug 2015 14:08:40 -0700

+1

Pontification is for those who wear funny hats.

Joe

---

From: Nico Williams <[email-masked]>
Date: Wed, 12 Aug 2015 16:41:40 -0500

On Wed, Aug 12, 2015 at 01:21:32PM -0700, Roy T. Fielding wrote:
> to write opinion pieces.  I consider them to be [...]

The IAB certainly publishes opinions.  The IESG basically publishes the
IETF's opinions.

> BTW, I think the choice of 1984 as an RFC number was atypically juvenile.

So what?  Have you seen the names they give to... laws, military
operations, and all sorts of things?  Have you seen our WG names?  Yeah,
it's OK.  And anyways, RFC1984's number is not juvenile, but a cultural
clue as to what it says, and it's a handy mnemonic.

> adopted because the alternatives it argues against are inherently stupid.

The 90s crypto wars ended on the side of RFC1984.  Are you saying that
RFC1984 came close to derailing that?  Do you have any proof that the
chorus of voices against Clipper and such had no impact?

The new crypto wars will too end the same way, if only because the
alternative is simply untenable for practical reasons.  Perhaps we
don't have to say anything.  But better safe than sorry.

Nico
--

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 12 Aug 2015 23:49:02 +0200

> patent and export licensing.
I was in the room at the Danvers plenary, and that was not the
impression I got.
In particular, at that time many people believed very strongly that
IPSEC, an IETF protocol, would be THE most useful tool for achieving
security, once it was finished.

Other RFCs at the time included RFC 1968, the PPP Encryption Control
Protocol, RFC 1969, the PPP DES Encryption Protocol, and RFC 1964, the
Kerberos Version 5 GSS-API mechanism.

A cynic would say that they were just making different wrong assumption
from the one Roy observed, but people seemed to strongly believe that
the IETF was developing protocols that required strong cryptography.

-- 
Surveillance is pervasive. Go Dark.

---

From: [email-masked]
Date: Wed, 12 Aug 2015 15:38:36 -0700 (PDT)

I am in complete agreement with Pete on this matter. If there's a need
for a BCP covering this matter - and I believe there is - write one. RFC 1984
isn't it.

Moreover, the more urgent this need is, the more important it is to dot
the i's an cross the t's.

				Ned

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 12 Aug 2015 16:31:36 -0700

> On Aug 12, 2015, at 2:49 PM, Harald Alvestrand <[email-masked]> wrote:
> 

Yes, certainly.  But, IPsec didn't require strong encryption be used;
it required an MTI algorithm of 56bit DES-CBC.  IPsec had algorithm and
key length options, like everything else at the time.

RFC1825:
   For interoperability throughout the worldwide Internet, all
   conforming implementations of the IP Encapsulating Security Payload
   MUST support the use of the Data Encryption Standard (DES) in
   Cipher-Block Chaining (CBC) Mode as detailed in the ESP
   specification.  Other confidentiality algorithms and modes may also
   be implemented in addition to this mandatory algorithm and mode.
   Export and use of encryption are regulated in some countries [OTA94].

> Kerberos Version 5 GSS-API mechanism.

RFC1968: "The strength of the protection
   is dependent on the encryption algorithm used and the care with which
   any 'secret' used by the encryption algorithm is protected."

All of this work was, of course, based on the premise that strong encryption
would be used when possible.  It simply wasn't required.  So, trying to read
such a requirement into RFC1984 doesn't make any sense, no matter how much
the reader might wish it to be true.

> the IETF was developing protocols that required strong cryptography.

I have no doubt that many people believed many things that they would have
found to be false had they bothered to check the details.  I am sure I
believed many such things twenty years ago.

....Roy

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 13 Aug 2015 07:31:46 +0200

> key length options, like everything else at the time.

At that time, 56bit DES-CBC was considered strong per the export rules.
What we were fighting against was 40bit RC4.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 13 Aug 2015 15:48:24 +0100

Eliot's two quotes nicely illustrate the dilemma of perfect encryption.

As engineers we should aim to address this dilemma rather than
simply declare it impossible, and opt for data privacy at all costs.

We have a social responsibility to design an internet that is rugged
from attack, that is fit for use by law-abiding people but does not
provide an impregnable conduit for the use of people that seek to
harm us.

My concern is that by elevating the status of RFC1984 we fail to
acknowledge the dilemma, and do not set a goal of designing
technologies that allow the internet to be used to reliably and
safely carry information for the law abiding, but still provide
the ability for those that we trust to protect us from harm
to perform that task.

- Stewart

On 12/08/2015 21:55, Eliot Lear wrote:
>> opinion piece by the IAB and IESG. Everything in it is phrased as 
>> such to avoid pissing off the people in the IETF who believe the 
> some.  But to put it only in those terms demonstrates a 
> misunderstanding of RFC 1984.  The document represents what was and 
> is, I believe, a strong consensus view that key escrow, key length 
> limitations, and export restrictions are technically harmful to 
> Internet users for all the reasons stated in the draft.  The points 
> made in the draft were technically indisputable then and are 
> indisputable now.  If we had to open up 1984 we simply wouldn't change 
> much, but we *would* make it a BCP. So why not just do so?
>
>> described have been adopted because the alternatives it argues 
>> against are inherently stupid. ....Roy 
>
> proposing key escrow and other bad ideas.  That we are here again now 
> is disheartening.
>
> York Times that called out Apple and Google on their approach.[1]  
> Last week there was an article in that same paper about how 
> wiretapping brought down a huge scam at Brazilian oil producer 
> Petrobras.[2]  Applying the sound logic of 1984 to these new examples 
> probably would be very helpful.  In addition, there have been massive 
> security failures involving escrowed keys. Highlighting that would 
> also be helpful.  All of these points would emphasize just how 
> timeless RFC 1984 truly is, and so should be recognized as a BCP.  
> Doing so may also facilitate a very much needed dialog between law 
> enforcement and the technical community.
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Aug 2015 08:10:15 -0700

On 8/13/2015 7:48 AM, Stewart Bryant wrote:
> We have a social responsibility to design an internet that 
...
> does not

Stuart,

When a goal is specified, it permeates the work.  The goal therefore
needs to have a practical basis for achievement, rather than merely
capturing a lofty and idealistic wish.  Otherwise, it winds up serving
as a distraction at best; at worst, it destroys efficacy.

In the current case, there is no line of technical effort that has been
put forward, which has any credible support from the knowledgeable
technical community, that supports the above goal without thoroughly
undermining the other essential goals.

To the extent that you know of a practical line of design effort that
can satisfy the above goal, without also creating the basic problems
that have been documented, please describe it.

d/

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 13 Aug 2015 17:14:51 +0100

> that have been documented, please describe it.
Dave

Many of the interesting cases can be addressed by some mixture of
extreme key fragmentation with escrow fragmented across a set
of organizations that are both unable and unlikely to collude, but
would co-operate with an appropriate third party if presented with
the appropriate justification.

Escrowed fragments would need to distributed across organizations
with no commonality of political or economic influence, but with
a common moral and ethical standing.

The absence of technical sophistication by many wrong doers would
mean that at least their communications would be addressable, which
would at least be a step in the right direction.

-Stewart

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Aug 2015 09:18:44 -0700

> the appropriate justification.

That's theory that could reasonably sound appealing.  Are there
real-world examples of a model like this showing the desired properties
that balance safety and utility?

We all generate a constant stream of logical wonderful theories.  The
pragmatics kill most of them.

This being an 'engineering' group rather than a 'research' group, we are
supposed to make agreements based on a solid knowledge of those pragmatics.

d/

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 13 Aug 2015 17:31:10 +0100

> supposed to make agreements based on a solid knowledge of those pragmatics.
The pragmatics of law enforcement is that you provide reasonable
protection for the rights of the law abiding whilst catching sufficient
of the unlawful that all but the most extreme in terms of
criminal sophistication, or lawlessness are discouraged.

In other words we need to apply engineering pragmatics that matches
the pragmatics of law enforcement.

- Stewart

---

From: "Joe Abley" <[email-masked]>
Date: Thu, 13 Aug 2015 12:33:13 -0400

> that balance safety and utility?

Management of root zone DNSSEC Key Signing Key (KSK).

A copy of the system master key (SMK) that wraps backup copies of the 
root zone KSK is distributed amongst independent "recovery key 
shareholders" who do not share affiliation with each other or with any 
of the root zone management partners. Each individual key share is 
useless; a threshold number (I forget the value) of them must be brought 
together in order for the SMK to be used. The application here is 
disaster recovery in the event that all HSMs fail, and the root zone KSK 
needs to be recovered from encrypted backups that are stored separately 
from the HSMs on smart cards.

There has never been an occasion when these backups have been needed 
(there have been no HSM failures), but the recovery procedures have been 
lab-tested and the SysTrust audit includes the collection of 
attestations (with photographic evidence, I think) that the SMK key 
shares in their tamper-evident bags are still accessible by the 
shareholders.

(I haven't been following this thread with enormous diligence, but this 
seems like a real-world, well-documented, internet-related answer to 
your question.)

Joe

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 13 Aug 2015 09:58:33 -0700

> On Aug 12, 2015, at 10:31 PM, Harald Alvestrand <[email-masked]> wrote:
> 

MTI algorithms (when not ignored) impact export control of the software,
not actual use.  If the powers that be said "you can't use more than 40bit
keys when communicating across borders", then nothing the IETF required
would have gone against it.  IPsec allowed 40bit RC4.  It still would have
been stupid and steadfastly ignored by most people, but that's how we
worked around the stupid.

....Roy

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Aug 2015 18:04:13 +0100

> Management of root zone DNSSEC Key Signing Key (KSK).

I don't think those are at all the same. The KSK case is basically
a once-off tiny-scale key storage thing run by relatively mutually
trusting parties where misbehaviour should be apparent or would be
pointless.

The mythical system Stuart is imagining would need to handle
extremely mutually untrusting parties at Internet scale in a system
that's basically supposed to support exactly the kind of thing that
would constitute misbehaviour in the KSK case.

So no, not the same in many ways, including the important aspect
that the KSK backup system is reality whereas the other is fantasy.

S.

PS: A nit, but I assume that it is not "copies" of the KSK you
meant but rather cryptographic shares in that key which are an
entirely different thing.

---

From: "Joe Abley" <[email-masked]>
Date: Thu, 13 Aug 2015 13:20:31 -0400

On 13 Aug 2015, at 13:04, Stephen Farrell wrote:

> I don't think those are at all the same.

Very good, then. Turns out that inferring the topic of conversation by 
1:100 sampling of messages in threads on this list is a bad idea.

> that the KSK backup system is reality whereas the other is fantasy.

:-)

> entirely different thing.

Yes, apologies for the loose description.

Joe

---

From: Sam Hartman <[email-masked]>
Date: Thu, 13 Aug 2015 13:54:34 -0400

>>>>> "Stewart" == Stewart Bryant <[email-masked]> writes:

    Stewart> On 13/08/2015 16:10, Dave Crocker wrote:
    Stewart> Dave

    Stewart> Many of the interesting cases can be addressed by some
    Stewart> mixture of extreme key fragmentation with escrow fragmented
    Stewart> across a set of organizations that are both unable and
    Stewart> unlikely to collude, but would co-operate with an
    Stewart> appropriate third party if presented with the appropriate
    Stewart> justification.

Stewart said that he was worried that bringing RFC 1984 to BCP would
discourage us from adequately considering law-enforcements' needs in our
work.
If the above sort of technical approach is what it would mean to
consider law-enforcement needs, I'd like to confirm that my intent in
supporting RFC 1984 to BCP is to discourage such work in the IETF.
I consider that best for the Internet.
There was a lot of discussion around these issues during the 1990's and
I generally support the arguments presented at that time which I believe
are a response to Stewart's technical objection.
Which is to say, I think the point Stewart is making has been consider
for 20 years and I really hope he's in the rough on this issue.
While we were mostly focused on Clipper in the 90's, we did discuss the
general problem of key escrow including distributed systems like the
above.
RFC 1984 points out one way in which such systems are ineffective:
multiple encryption.
So, since I believe such a system would not be effective, and since I
think it would tend to have harmful properties, I do not support it, and
I do believe we as a community are saying we don't support this when we
move RFC 1984 to BCP.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 13 Aug 2015 19:59:40 +0200

Hi,

As I wrote, I have no problem with 1984 going to BCP, but this line of
logic is what most concerns me:

> RFC 1984 points out one way in which such systems are ineffective:

That is the same as saying that people can evade telephone taps by using
encryptors at either end.  And yet the vast majority do not.  This is
why a dialog with law enforcement should happen.  The 1990s were a time
of Operation Sun Devil and when people inside Law Enforcement didn't
know how to tie their shoes with regard to the Internet.  Things are
different now.  That dialog is really important.

Eliot

---

From: james woodyatt <[email-masked]>
Date: Thu, 13 Aug 2015 11:23:03 -0700

>    (IAB and IESG Statement on Cryptographic Technology and the Internet)

I support this change.

And I would like the IETF to consider issuing a new Informational document to update RFC 1984 for the purpose of expanding on the following statement, which appears in the original text:

>    [...] But PFS is generally incompatible with schemes
>    involving escrow of private keys.  (This is an oversimplification,
>    but a full analysis would be too lengthy for this document.)

I suppose it’s possible (I haven’t searched) that a document has already been written that contains this full analysis, in which case it should suffice to mark RFC 1984 as updated by that document. If such a document does not exist, then I really think it’s long past time that one be written to answer the predictable complaint from non-technical policy-makers that the IETF nerds aren’t communicating effectively why a naïve approach to their government policy problems is doomed to fail.

—james

---

From: "John Levine" <[email-masked]>
Date: 13 Aug 2015 22:04:43 -0000

>that balance safety and utility?

Also scalability.  In the Apple iMessage system, every user has a
separate key pair and only sends the public key to the Apple
directory.  How do you fragment and escrow all umpteen million of
the private keys?

A system in which Apple held a master key would be a major redesign
and a major step backwards.  Even a system where a key, once
disclosed, allowed access to all future traffic with that key would
not be desirable.

R's,
John

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 13 Aug 2015 23:17:29 +0100

> different now.  That dialog is really important.
I agree. This is an area that we are not well qualified to understand and
we need to have the conversation.

One of the challenges that the IETF has is to remain the technical design
authority for the Internet, and failure to engage with important 
stakeholders
diminishes that our credibility in that role.

- Stewart

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Aug 2015 11:17:32 +1200

> the pragmatics of law enforcement.

I think this is irrelevant to RFC 1984. Our point then, which is still
true, is that bad actors are able to use strong cryptography without
escrowing their keys, thus creating their own "impregnable conduit".
So key escrow is utterly pointless in terms of defeating truly bad
actors, although it does help governments to spy on more law-abiding
citizens. When spying on bad actors, you have no choice but to
assume that they have an "impregnable conduit" and use other
techniques.

    Brian

---

From: Michael StJohns <[email-masked]>
Date: Thu, 13 Aug 2015 20:05:42 -0400

>directory.  How do you fragment and escrow all umpteen million of

You don't.  You create some number of key pairs for escrow and each session key is encrypted under both the normal key pair and one of the escrow key pairs.  After that's its mostly a database problem - but lots of communities deal with very large data set management.   If you want better policy control you impose some sort of N of K model to reconstitute the encrypted keys. 

I'm not recommending this or opposing it - just saying that its possible in pretty much any case to design some sort of key recovery system that meets a specific policy and that is manageable.  Even for 100s of millions of keys. 

Mike

---

From: Eliot Lear <[email-masked]>
Date: Fri, 14 Aug 2015 08:15:27 +0200

Brian,

On 8/14/15 1:17 AM, Brian E Carpenter wrote:

> citizens. When spying on bad actors, you have no choice but to assume
> that they have an "impregnable conduit" and use other techniques. Brian 

Let's please split this in half.  Technically up until the last sentence
you are absolutely correct, and it is important that policy makers
understand the limitations of any sort of key escrow regime - or key
size limitation.  And they should understand the risks of disgorging
private keys.  RFC 1984 does a great job of explaining that, and that's
why it's perfectly fine for this to be a BCP in my mind.

But that last sentence is the crazy part of this debate because long
experience has shown that even when the technology has been available,
many bad guys haven't availed themselves of it.  Experience also shows
that key escrow can and has been done for storage purposes.  But it
comes with substantial risks, and the biggest one is that someone will
break into the escrow and steal keys.[1]  Again, OPR's break-in should
give people long pause before creating a large central store of
sensitive information.  This is the sort of dialog with policy makers
that needs to occur.

Eliot
[1]
http://www.cnbc.com/2014/10/21/china-hackers-may-have-hacked-apples-icloud.html

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 13 Aug 2015 12:06:10 -0400

> that have been documented, please describe it.

Yes, exactly. "Send code."

--John

---

From: John Leslie <[email-masked]>
Date: Fri, 14 Aug 2015 11:19:15 -0400

> Yes, exactly. "Send code."

   Just so we don't lose context,
> the ability for those that we trust to protect us from harm

   (There is, of course, no such thing as an "impregnable conduit".)

   If Stewart follows up, I hope he will explain what he meant by
"those that we trust to protect us from harm".

--
John Leslie <[email-masked]>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 14 Aug 2015 17:07:00 +0100

>     (There is, of course, no such thing as an "impregnable conduit".)
There are obviously degrees of protection, but the point is that
many communications channels are protected to the point that
they cannot be decrypted in a time that is useful to the law
enforcement world.
> "those that we trust to protect us from harm".
Well I for one trust our local police forces to do this by their best
effort at detecting and bringing to justice criminals and interdicting
those planning criminal activities. That is the service that we pay them
to do through our taxes, and as far as I can tell that is their intent.

The security services are rather more opaque, but in democracies
they are paid through our taxes to protect their citizens from harm.

- Stewart

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Aug 2015 08:41:13 +1200

On 14/08/2015 18:15, Eliot Lear wrote:
> many bad guys haven't availed themselves of it.  

Of course, or they have made mistakes that weaken the strong crypto.
But if your job is to look for the really bad guys, you MUST assume
that they are using strong crypto with inaccessible keys. It's
irresponsible to assume anything else.

    Brian

> Experience also shows

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 15 Aug 2015 09:21:43 +0100

Brian

Let's not boil the ocean here. Many criminals use COTS solutions.
Disabling their technology in a way that is still provides satisfactory
for privacy for ordinary citizens would be a useful engineering goal
that pragmatically addresses both their need for privacy and the
need for law enforcement.

I understand that the really bad people will put in place systems
that are harder to decrypt, but let's try to move that to the realm
of bespoke systems where there is a chance that they will make
mistakes.

- Stewart

---

From: "John Levine" <[email-masked]>
Date: 15 Aug 2015 12:49:44 -0000

>need for law enforcement.

It seems to me there's some straightforward solutions here.  As the
"Keys Under Doormats" paper notes, the same devices are used all over
the world and it is unlikely that countries would accept key escrow
that they don't control.  Hence the obvious way to do key splitting is
to send a piece to the government of every country where they sell,
say, iPhones.  If the governments of China, Vietnam, Pakistan, India,
Saudi Arabia, Israel, Nigeria, Venezuela, Bolivia, and Brazil (and the
US) all agree that something is bad enough to disclose, it must be
pretty bad.

On the other hand, if that's a bad idea, or it's ridiculous, I'd be
interested in seeing the research comparing the largly hypothetical
costs of secure crypto to the easily measured costs of having our
high tech devices shut out of all those markets.

R's,
John

---

From: John Leslie <[email-masked]>
Date: Sat, 15 Aug 2015 10:10:51 -0400

John Levine <[email-masked]> wrote:
> that they don't control.

   Excellent point!

   If we do engineer a protocol such that keys can be escrowed without
effectively exposing those keys to every competent hacker (for now lets
just laugh, not argue whether that's possible!), _who_ do we give the
escrowed keys _to_?

> Hence the obvious way to do key splitting is to send a piece to the
> government of every country where they sell, say, iPhones. If the
> governments of China, Vietnam, Pakistan, India, Saudi Arabia, Israel,
> Nigeria, Venezuela, Bolivia, and Brazil (and the US) all agree that
> something is bad enough to disclose, it must be pretty bad.

   Cute idea!

   (Of course, our competent hacker could just hack _all_ those
countries' escrow storage; but that's likely to prove hard in Israel.)

> high tech devices shut out of all those markets.

   Another excellent point.

   Governments _are_ going to control manufacturers within their bounds.
Backdoors _will_ show up in implementations, if needed to get permission
to sell in certain countries.

   Which, to me, raises the question of whether we might do well to
standardize something _not_ for the multi-national companies, but for
the smaller single-nation companies to provide...

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Aug 2015 11:05:14 +1200

I really believe this discussion completely misses the point.

RFC 1984 says:

   Even if escrowed encryption schemes are used, there is nothing to
   prevent someone from using another encryption scheme first.
   Certainly, any serious malefactors would do this; the outer
   encryption layer, which would use an escrowed scheme, would be used
   to divert suspicion.

In other words: even the most Byzantine escrow system is useless in the
face of a bad actor who chooses to implement and use a non-escrowed
system, concealing its existence using a government-approved escrowed
system on top. Escrow is only useful against law-abiding people who
trust the government(s) in the first place.

Regards
   Brian

---

From: Eliot Lear <[email-masked]>
Date: Mon, 17 Aug 2015 09:06:36 +0200

On 8/16/15 1:05 AM, Brian E Carpenter wrote:
> system on top. 

Or on bottom.  Whichever.  The point is well made in 1984.

> Escrow is only useful against law-abiding people who

It's that assertion that has been repeatedly proven false with all
manner of other technology.

Eliot

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 17 Aug 2015 14:09:03 +0200

> manner of other technology.

{{citation needed}} - in other debates, I've heard "proof" claimed for
all sorts of things; sometimes it's things I believe; sometimes it turns
out that the "proof" is itself hugely controversial.

You might have convincing examples, Eliot, but I can't think of any at
the moment, so I need your help to be reminded of them.

---

From: Eric Burger <[email-masked]>
Date: Mon, 17 Aug 2015 08:29:45 -0400

I’ve been sitting on the sidelines because most of the arguments for and against making 1984 a BCP have been said. I am slightly on the “If RFC2026 can be a BCP, why cannot 1984 be a BCP” side of the fence.

However, since it appears we want to promote 1984 to BCP for political reasons, to be effective we need to be bulletproof in our arguments. Harald has a point here - if we are going to say ANYTHING around the press release that comes with the BCP, it has to be 110% accurate [sic].

> On Aug 17, 2015, at 8:09 AM, Harald Alvestrand <[email-masked]> wrote:
>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 17 Aug 2015 16:57:03 +0200

Harald,

> out that the "proof" is itself hugely controversial.

I did provide a citation to this list on August 12th that contradicted
what Brian wrote above:

Here's a case where the people in question *could* have gone to some
lengths to protect their communications but did not.  That is
practically speaking the entire history of wiretapping.[*]  That doesn't
mean we break our protocol suite to wire tap, but it also doesn't mean
that we overstate the negatives when talking to others.  1984 makes
clear that use of escrow and other approaches has serious side effects
that can negatively impact security.  That statement is good enough.[**]

Eliot

[*] I'm reminded of another example of this sort of thing.  Many years
ago, in the middle of winter, my parents' house was broken into.  They
called the police and the police quickly arrested a person who lived
nearby, having tracked him by his footprints in a snowy field that links
many of the houses.  Had he simply walked on the clear sidewalk, he
probably wouldn't have been caught.  Not all criminals are super
geniuses.[1]

[**] Elsewhere it has been asserted that the ability to create a
functioning escrow approach that scales.  I think that's very likely
true, but if it turns out not to be, we should revisit 1984 at that
time, as to whether or not it remains appropriate as a BCP.

[1] https://www.flickr.com/photos/ladystephanie/10227056515

---

From: Eliot Lear <[email-masked]>
Date: Mon, 17 Aug 2015 17:29:11 +0200

My typing is nowhere near as nuanced: slight correction below:

On 8/17/15 4:57 PM, Eliot Lear wrote:
> practically speaking the entire history of wiretapping.[*]  That
> doesn't mean we break our protocol suite to wire tap, but it also
> doesn't mean that we overstate the negatives when talking to others. 
> 1984 makes clear that use of escrow and other approaches has serious
> side effects that can negatively impact security.  That statement is
> good enough.[**]
>
> Eliot
>
> nearby, having tracked him by his footprints in a snowy field that
> links many of the houses.  Had he simply walked on the clear sidewalk,
> he probably wouldn't have been caught.  Not all criminals are super
> geniuses.[1]
>
> [**] Elsewhere it has been asserted that *there is no* ability to
> create a functioning escrow approach that scales.  I think that's very
> likely true, but if it turns out not to be, we should revisit 1984 at
> that time, as to whether or not it remains appropriate as a BCP.
>

Sorry about that.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 17 Aug 2015 16:30:23 +0100

>> out that the "proof" is itself hugely controversial.
Fortunately the majority of criminals are not so smart, and fundamentally
that is the edge that makes law enforcement possible. A Google search will
produce many examples, for example the bank robber that confessed on
youtube, or the motorcyclist that posted video proof that he could ride 
a bike
at 148mph in a 70 limit.

So whilst the clever criminals may avoid escrow, most would use whatever
communications technology they were provided with, and of course the
clever ones may well accidentally stray into escrow enough of the time
to make them vulnerable.

- Stewart

---

From: Eric Burger <[email-masked]>
Date: Mon, 17 Aug 2015 11:44:40 -0400

I could be cynical and offer that this is the argument FOR a key escrow scheme. It will be great for business for secure communications companies to sell enterprises (“Hey - do you want your competition to listen in to your communications? No? You need our stuff!”).

Alternatively, would this mean that only the smart, hardened criminals and IETF folks will have privacy? Interesting bedfellows...

> On Aug 17, 2015, at 11:29 AM, Eliot Lear <[email-masked]> wrote:
> 
>> I did provide a citation to this list on August 12th that contradicted what Brian wrote above:
>> 
>> Here's a case where the people in question could have gone to some lengths to protect their communications but did not.  That is practically speaking the entire history of wiretapping.[*]  That doesn't mean we break our protocol suite to wire tap, but it also doesn't mean that we overstate the negatives when talking to others.  1984 makes clear that use of escrow and other approaches has serious side effects that can negatively impact security.  That statement is good enough.[**]
>> 
>> Eliot
>> 
>> [*] I'm reminded of another example of this sort of thing.  Many years ago, in the middle of winter, my parents' house was broken into.  They called the police and the police quickly arrested a person who lived nearby, having tracked him by his footprints in a snowy field that links many of the houses.  Had he simply walked on the clear sidewalk, he probably wouldn't have been caught.  Not all criminals are super geniuses.[1]
>> 
>> [**] Elsewhere it has been asserted that there is no ability to create a functioning escrow approach that scales.  I think that's very likely true, but if it turns out not to be, we should revisit 1984 at that time, as to whether or not it remains appropriate as a BCP.
>>

---

From: Dave Crocker <[email-masked]>
Date: Mon, 17 Aug 2015 09:21:13 -0700

On 8/17/2015 8:30 AM, Stewart Bryant wrote:
> fortunately the majority ofcriminals are not so smart, and
> fundamentally that is the edge that makes law enforcement possible.

Stewart,

So the goal you are espousing is to globally embed a mechanism for
compromising privacy, in order to catch stupid criminals, knowing that
it will be useless against serious and intelligent criminals?

Your premise that the result would "provide[] satisfactory privacy for
ordinary citizens" is, so far, counterfactual, given the many and
continuing revelations that document state-based compromises.

Based on experience to date, at best what you propose is an open and
very difficult research topic, at the intersection of computer science,
engineering, operations, politics and sociology.

The issue here is not a question of a component bit of key distribution
design, but rather of system-level, long-term efficacy in protecting
privacy in the face of sustained compromise efforts by well-funded,
dedicated and highly intelligent adversaries.

d/

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 17 Aug 2015 17:50:27 +0100

> it will be useless against serious and intelligent criminals?
... serious and intelligent criminals that never make a mistake. Fortunately
a relatively rare group.

... and when you say global,  one not would put in place
a single global repository for any single element of the system.

What is needed is to raise the bar to the point where it is difficult
but not impossible for duly authorized access (subject to scrutiny),
but close to the ideal for unauthorized access.
> continuing revelations that document state-based compromises.
I am not advocating a system where a state can read stuff at will
which is where we were (are?), but I am concerned that swinging the
pendulum to the point where reading data for what most would
consider legitimate purpose is prevented.
> engineering, operations, politics and sociology.
Yes, it is a hard problem, but that does not make it the less worthwhile.
> dedicated and highly intelligent adversaries.
There are many parts of the Internet that need to be protected from
such a concerted attack, and with much greater payoff than reading
the traffic of individuals.

- Stewart

---

From: Dave Crocker <[email-masked]>
Date: Mon, 17 Aug 2015 10:16:02 -0700

Stewart,

You might want to add 'never' as a qualifier but I will suggest that it
is an irrelevant distraction, mostly serving to try to move the topic to
an ad absurdum requirement for mathematical perfection that is not at
all relevant to real-world, practical concerns here.

> a single global repository for any single element of the system.

Wrong focus.  You are proposing modifications to global standards that
will support state-based privacy compromise.  I never said anything
about a single repository.

What I am referring to is a modification to global standards for
privacy, in support of an organized ability to compromise that privacy.

> but close to the ideal for unauthorized access.

Again, for your overall statement, you have described a research topic,
not a topic ready for standardization by the IETF and frankly, therefore
not ready for support by the IETF.

But to the specific reference to 'scrutiny', it presumes adequacy of a
particular approach using an oversight component, when there is amble
evidence that, to date, such an approach to protection works somewhere
between 'poorly' and 'not at all'.

> consider legitimate purpose is prevented.

The pendulum swung to that latter capability long ago.  Hence Brian's
point that those who are serious about solid and (essentially)
unbreakable encryption have long had access to it /and will continue to
have access to it, independent of any embedded compromise mechanisms
that we might define/.

Rather, what you are proposing is that we make sure such a capability is
not obtained casually.

> Yes, it is a hard problem, but that does not make it the less worthwhile.

The IETF should not espouse standardization of capabilities that remain
open and very difficult research problems.  If and when the issue
becomes amenable to large-scale engineering, implementation and
operation across very large numbers of independent administrations and
states, the IETF could reasonably re-visit the topic.

As of now, the most we should say is that it is a research topic and we
do not know how to design it adequately.

> the traffic of individuals.

Yes, well, that's my point.  I suspect however that I was not clear
enough in my reference.

The attack(s) I am talking about would be from the state agencies
seeking to compromise the purported protections ensuring safety against
misuse of the IETF-created, embedded compromise mechanism.

d/

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Aug 2015 08:30:30 +1200

> Alternatively, would this mean that only the smart, hardened criminals and IETF folks will have privacy? Interesting bedfellows...

That is, and has always been, my point. The people society most has to fear
are smart enough to avoid escrow, very possibly by paying for the expertise.

To look at it slightly differently, from the bad actor's viewpoint, strong
crypto with key escrow is equivalent to weak crypto, because the authorities
can read the traffic (assuming that metadata surveillance has made the traffic
seem interesting).

Please do not assume that the really bad actors are unaware of this. They're
not stupid and they have a lot of money.

   Brian

---

From: Eliot Lear <[email-masked]>
Date: Tue, 18 Aug 2015 07:12:01 +0200

Hi,

>> I could be cynical and offer that this is the argument FOR a key escrow scheme. It will be great for business for secure communications companies to sell enterprises (“Hey - do you want your compe…

As it happens, enterprises are huge users today of key escrow schemes
for storage.  And nobody in this discussion would be arguing to mandate
escrow.  In fact I'm not even advising escrow.  Quite the contrary,
really.  All I'm saying is that it is not reasonable to argue extremes,
and one extreme is that we need to assume in this case that the law
enforcement goal is perfect access to everything.

> not stupid and they have a lot of money.

And please do not assume that most bad actors have a frigging clue.  The
effectiveness existing law enforcement  is a proof point against that
assumption.  That does not mean that this organization should advocate
for escrow.  I just want us not to look like fools when making our point.

Eliot

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 18 Aug 2015 09:59:58 +0200

> for escrow.  I just want us not to look like fools when making our point.

I have noted that the heat of this discussion increased sharply when
Apple and Google started device encryption by default - that is, people
who did not care (before meeting law enforcement) would get their data
encrypted. This obviously also means that bad actors who did not care
would get their data encrypted - which means that they did not *need* a
clue in order to be protected.

I think this illustrates the natural tendency of technology adoption:
Things that required significant smarts 10 years ago is now just "what
everyone does"; things that requires significant smarts now will be
"what everyone does" in 10 years - unless steps are taken to stop it.

RFC 1984 was not about describing the state of the world in 1996. It was
about influencing the state of the world in 2006 (and 2016!) - helping
along the things we thought would make the world better by then
(deployment of encryption) and defeating the proposals we thought would
make the world a worse place (among other things, mandatory key escrow
and all the limitations on technology that such a mandate would have to
impose in order to be effective).

That's the perspective we need to have.

---

From: t.p. <[email-masked]>
Date: Tue, 18 Aug 2015 09:41:28 +0100

I oppose recognising RFC1984 as a BCP on two grounds.

First, most people outside the IETF do not understand the difference
between the various categories of IETF documents (as I am reminded of
when I see well known manufacturers talk of their conformance to an
I-D).  Yes, there are corners of the world, important corners, that do
understand but most do not so unless this reclassification has a
specific and limited audience in mind, then it is a pointless exercise
in inward-looking politics.

Second, the document itself is dated.
"As more and more companies connect to the Internet,  .. " was a good
idea in 1995 - now it just looks silly.  Likewise,
"The Internet is becoming the predominant vehicle for electronic
   commerce and information exchange. "
Most people outside those in the industry do not understand how a mobile
does what it does, they just know that it is how they do it.  For them,
as for most people, the mobile phone/cell phone/ NYOP/..  is the
predominant vehicle and they are unaware of what role, if any, the
Internet plays therein.

The language is not wrong, just quaint, dated, an interesting slice of
history.

If we want a BCP, we should write one.

Tom Petch

---

From: Eliot Lear <[email-masked]>
Date: Tue, 18 Aug 2015 18:58:21 +0200

Hi Harald,

> That's the perspective we need to have.

There is what is technically advisable, technically possible,
technically inadvisable, and simply impossible.  The law enforcement
community may lack this understanding. 

There is that which is required by law enforcement and desired by law
enforcement, and what would be a "nice to have".  Our community
certainly lacks this understanding.

When they think what we are doing is harming their interests, it is best
that the above situation be resolved.  That has been my point.

Eliot

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 20 Aug 2015 12:22:49 +0200

Subject: Re: Last Call: Recognising RFC1984 as a BCP Date: Mon, Aug 10, 2015 at 10:23:15AM -0700 Quoting Paul Hoffman ([email-masked]):
> Yes, please. What was discussed in 1996 really is a best practice today, and
> it has certainly been made the current practice.

I would like to add my support for making RFC1984 a BCP.  

I have read the document, and what needed to be said then stands today
as something, sadly, still in need of saying. The document, then is
"current" in the most fitting way.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Yow!  I want to mail a bronzed artichoke to Nicaragua!

---

From: Avri Doria <[email-masked]>
Date: Thu, 20 Aug 2015 10:06:41 -0400

hi,

Appreciated the opportunity to reread RFC1984 and marveled at the degree
to which it is currently best practice and very timely informational advice.

Very supportive of making this BCP.

avri

>> it has certainly been made the current practice.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

---

From: John Curran <[email-masked]>
Date: Thu, 20 Aug 2015 10:24:02 -0400

> On Aug 15, 2015, at 7:05 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Brian - 

I have no view either way on the merits moving RFC1984 to BCP status, 
but would note that (at least in my limited experience) law enforcement
activities (LEA) often seek supporting or corroborating information that is 
not  the direct communications of the alleged perpetrators.  Even presuming
knowledgable criminals using encryption that is over/above for dialogue with 
their accomplices, that does not preclude the potential usefulness (from 
LEA’s perspective) from being able to obtain more mundane, but related 
communications (e.g. with suppliers, future victims, etc.)

It’s quite possible that the appropriate tradeoff for society continues to be 
that as documented in RFC1984, but it should be recognized as an actual
tradeoff and not an an approach without any impact to lawful enforcement
activities (as might be implied from your comments above.)

/John

Disclaimer: my views alone; no LEA personnel were harmed in the
production of this email.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 20 Aug 2015 07:37:20 -0700

On 8/20/2015 7:24 AM, John Curran wrote:
> not  the direct communications of the alleged perpetrators.  E

John, et al,

Technical work is best guided by substantive case analyses or, at least,
documentation of a range of concrete, real-world details.  Having a
general assertion, of the type you offer here, is useful as a starting
point in discussion, but not as an ending point.

What is needed is followup that provides details that compose a serious
and substantive case for the utility you describe.

d/

---

From: Randy Bush <[email-masked]>
Date: Thu, 20 Aug 2015 07:47:20 -0700

> It’s quite possible that the appropriate tradeoff for society
> continues to be that as documented in RFC1984, but it should be
> recognized as an actual tradeoff and not an an approach without any
> impact to lawful enforcement activities (as might be implied from your
> comments above.)

sorry, i can't resist

We should not be building surveillance technology into standards.  Law
enforcement was not supposed to be easy.  Where it is easy, it's called a
police state.  -- Jeff Schiller

---

From: John Curran <[email-masked]>
Date: Thu, 20 Aug 2015 11:16:53 -0400

> and substantive case for the utility you describe.

Dave -

I imagine that the IETF will gather such as a result of their engagement
with the affected communities.

/John

---

From: John Curran <[email-masked]>
Date: Thu, 20 Aug 2015 11:30:58 -0400

> police state.  -- Jeff Schiller

Randy - 
 
  Actually, that is a perfect example of my point - Jeff’s quote (with respect
  to not including surveillance technology) actually acknowledges that there 
  is an impact as a result that choice; i.e. ‘LE not supposed to be easy.’

  That’s quite different than some of the assertions on this list implying that 
  RFC1984 has no impact to LEA activities…  If the IETF is going to make
  a statement, it should be an intellectually honest one and acknowledge
  that there could be an LEA impact, but even so, that outcome is still the 
  desirable tradeoff in the circumstances.  

/John

Disclaimer: my views alone.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Aug 2015 16:43:48 +0100

On 20/08/15 16:30, John Curran wrote:
>>> Itâ€™s quite possible that the appropriate tradeoff for society
>   Actually, that is a perfect example of my point - Jeffâ€™s quote (with respect
>   is an impact as a result that choice; i.e. â€˜LE not supposed to be easy.â€™
> 
>   Thatâ€™s quite different than some of the assertions on this list implying that 
>   RFC1984 has no impact to LEA activitiesâ€¦  If the IETF is going to make

RFC1984 is about export and mandatory key escrow. That is related
to but not the same as so-called lawful intercept. RFC2804 does
deal with the latter explicitly. So I don't think that we need to
modify 1984 to talk about what is covered by 2804.

Some folks did make the point earlier that we ought "promote" both
1984 and 2804 to become one new BCP, which could be done. I only
so far saw two folks in favour of that, I assume on the basis that
both RFCs are today in a similar state and the topics, while different,
are related. The argument so far raised against was that there was
at the time (and still seems to be now) much better support for
what 1984 says (which is different to it being a BCP or not) than
was the case for 2804 was that was written.

For me, I think they're different enough that they'd be better
handled separately but if there are more arguments those would be
good to hear.

S.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 20 Aug 2015 11:16:18 -0500

Hi, Stephen,

On Thu, Aug 20, 2015 at 10:43 AM, Stephen Farrell <[email-masked]
> wrote:

> handled separately but if there are more arguments those would be

That sounds about right to me.

Even if RFC 1984 and RFC 2804 do end up in the same BCP, they don't have to
fate-share in discussions about whether to advance the two documents, and
if RFC 2804 turns out to need changes, handling them as a bundle would just
slow down advancing RFC 1984 to BCP (if it turns out we have consensus to
do that).

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Aug 2015 08:53:02 +1200

On 21/08/2015 03:30, John Curran wrote:
>   RFC1984 has no impact to LEA activities…  

I hope I've been consistent in asserting that it has no effect on *seriously
bad actors*. Small time crooks and run of the mill copyright infringers are
a different matter, but there are other ways of catching them.

   Brian

>   If the IETF is going to make
> .

---

From: Eliot Lear <[email-masked]>
Date: Fri, 21 Aug 2015 07:49:52 +0200

Hi Brian,

On 8/20/15 10:53 PM, Brian E Carpenter wrote:
> I hope I've been consistent in asserting that it has no effect on
> *seriously bad actors*. 

IMHO you have, and FWIW I agree.

> Small time crooks and run of the mill copyright infringers are a
> different matter, but there are other ways of catching them. 

You have a funny definition of "small time", given the Petrobras example
I highlighted.  As to whether or not there are other ways of catching
crooks, that is an assertion that you cannot prove; and it is well
outside our area of expertise, as an organization.

Eliot

---

From: John Curran <[email-masked]>
Date: Fri, 21 Aug 2015 13:03:12 -0400

On Aug 21, 2015, at 1:49 AM, Eliot Lear <[email-masked]> wrote:
> ... As to whether or not there are other ways of catching

That is probably one of the reasons why the IETF (as a formal endorsor of the
principle of transparency in standards development [1]) goes out of its way to
make sure that there is adequate advance public notice of proposed standards
development activities and the scope of work to be undertaken; i.e. so that those
parties with expertise (and who might be affected) have the opportunity to fully
engage in the process.

/John

[1] open-stand.org <http://open-stand.org/>