Subject: [saag] keys under doormats: is our doormat ok?

From: Stephen Farrell <[email-masked]>
Date: Sun, 12 Jul 2015 13:58:44 +0100

Hiya,

I'm sure a bunch of you have seen [1] and various reports of
potential government silliness that presumably prompted that.
So I just re-read RFC1984 [2] and I think it still does a good
enough job of setting out the IETF's position on the topic.

Since that RFC is almost 20 years old, I thought I'd check on
here if folks think anything more needs to be done in the IETF.
If there were, then it'd be timely to talk about that in Prague.

However, I think we're ok already thanks to RFC1984 but please
do say if you think something more needs to be done in the IETF.
(More no doubt needs to be done outside the IETF context, but
I'm not asking about that.)

Thanks,
S.

[1]
http://dspace.mit.edu/bitstream/handle/1721.1/97690/MIT-CSAIL-TR-2015-026.pdf
[2] https://tools.ietf.org/html/rfc1984

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 12 Jul 2015 17:02:17 +0200

> do say if you think something more needs to be done in the IETF.

The document is sometimes dismissed as being almost 20 years old, and
that it does not reflect current consensus among IAB/IESG.  Revising the
document (with as little changes as possible) and getting that approved
again would be useful, in my mind.

/Simon

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 12 Jul 2015 09:26:52 -0700

> again would be useful, in my mind.

I would say the opposite: people respect that our opinion from 20 years 
ago remains the same.

--Paul Hoffman

---

From: Ira McDonald <[email-masked]>
Date: Sun, 12 Jul 2015 12:36:24 -0400

Hi,

I respectfully suggest that, just as IEEE and ISO periodically reconfirm
standards, this important IAB/IESG RFC 1984 should be minimally
changed and re-published ASAP.

In my own experience, most non-IETF literate computer people tend
to dismiss very old RFCs as no longer relevant.

Cheers,
- Ira

On Sun, Jul 12, 2015 at 12:26 PM, Paul Hoffman <[email-masked]>
wrote:

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

---

From: Yoav Nir <[email-masked]>
Date: Sun, 12 Jul 2015 20:55:28 +0300

> to dismiss very old RFCs as no longer relevant.

I disagree. Publishing an update signals that our opinion has evolved. It
hasn't, even if the technology has evolved to make software the focus
rather than hardware. Besides, this kind of document is a huge rathole, and
I don't believe any minimal changes would be worth the hassle.

Yoav

-- 
Sent from MetroMail

---

From: joel jaeggli <[email-masked]>
Date: Sun, 12 Jul 2015 11:09:13 -0700

On 7/12/15 8:02 AM, Simon Josefsson wrote:
> that it does not reflect current consensus among IAB/IESG.

I'm not sure why someone would conclude that. if the consensus position
were elsewhere, we have abundant opportunity to revisit that. The
discussion that lead to RFC 7258 being one such opportunity.

Positions based on principles probably don't require a whole lot of
reconsideration once arrived at. There are not insofar as I as I am
concerned alternatives to working  trustable encryption systems.

>  Revising the

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 12 Jul 2015 20:10:28 +0200

> I disagree. Publishing an update signals that our opinion has evolved.
> It hasn't, even if the technology has evolved to make software the focus
> rather than hardware. Besides, this kind of document is a huge rathole,
> and I don't believe any minimal changes would be worth the hassle.

I completely agree.

Just as we elevated RFC 20 to STD, we could still elevate it to BCP -- a
status that, IIRC, was just becoming available at the time RFC 1984 was
published.

Grüße, Carsten

---

From: Dave Crocker <[email-masked]>
Date: Sun, 12 Jul 2015 15:28:04 -0700

> status that, IIRC, was just becoming available at the time RFC 1984 was

First, in the world of politics -- and any other environment that has
folk looking to squash views they don't like -- people will use anything
they can find to undermine such views.  The fact that a decision is 20
years old really does sway some folk.  It does not matter whether it
should.  What matters is whether such folk matter.

As often as we have people conducting protracted threads on IETF lists
with silly crazies, on the off-chance that someone, somewhere, will take
the crazy seriously, we need to pay attention to the potential that the
IETF position of 20 years ago will be dismissed because it was made 20
years ago.

     The question is not merely whether our views have changed,
     but whether they apply to the current issue as well as the
     one 20 years ago.

     To have a consensus view that the current issue is the same
     as 20 years ago is an example of something that constitutes new
     work.  So even if we think there is nothing new to say, there is
     something extremely important to say that is new.

I will suggest that it would be worth publishing a revised version of
the previous RFC, with the addition of some text that explains how that
previous decision applies to the current topic.  And or how the current
topic is the same as the previous topic and that the IETF position
remains now as it was then.

I will also suggest that we ought to have the IETF review of the draft
RFC for this include a segment at an IETF plenary.  However we aren't
likely to get a draft at that stage by 10 days from now and we almost
certainly should not wait until the next IETF.

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 of the room' be taken during the plenary.
And that the result of that polling be cited in the IETF's documentation
about the intended draft and then in the draft itself.

I'm glad to offer review services for the bulleted list and/or the draft.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Christian Huitema <[email-masked]>
Date: Mon, 13 Jul 2015 00:23:50 +0000

> 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 of the room' be taken during the plenary.

General agreement, but I would rather not call this a revision. Maybe something like "reaffirm."

> And that the result of that polling be cited in the IETF's documentation about the intended draft and then in the draft itself.

Yes.

-- Christian Huitema

---

From: Watson Ladd <[email-masked]>
Date: Sun, 12 Jul 2015 21:47:03 -0700

> IETF position of 20 years ago will be dismissed because it was made 20

The other factor is that we are entirely irrelevant to the discussion
this time around. Solutions like TextSecure use proprietary protocols
and aren't federated at all. It's not like when we were the place
where IKE2 and co were standardized, in which case our opinion
mattered. Now it's about the strength of our arguments, and the extent
(minimal) to which we appear to represent a cross-section of the
relevant industry.

> remains now as it was then.

If you actually read RFC 1984, you will note that it lists 4 policies
considered bad. One of those is mandating that keys are in the hands
of a third party, which is what is being proposed today. What would
this proposed revision add that would clarify that this is what is
being talked about? I do think we could have done a lot better: RFC
1984 doesn't contain a whole lot of argument: only conclusions. Don't
expect a repeat to be listened to.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 13 Jul 2015 14:28:50 +0100

Hiya,

On 12/07/15 23:28, Dave Crocker wrote:
> RFC for this include a segment at an IETF plenary. 

Just as a point of information for those who're considering there
may be external-to-the-IETF benefits in some form of renewal of
the relevant content from RFC 1984...

One reason I figured RFC 1984 is still ok is that the IAB have quite
recently weighed in with an even stronger recommendation "that
encryption be deployed throughout the protocol stack." [1] And while
that's an IAB statement and hasn't been through the IETF consensus
process, and while that doesn't directly touch on mandated-key-escrow-
silliness, it does refer back to RFC 1984, as well as going further.

So I reckon that from a non-IETF perspective, [1] probably achieves
as much as we'd achieve with any easy method of "renewing" RFC 1984.
(I'm also not sure what "renewing" 1984 might mean exactly but I'm
sure we could figure some mechanics that'd work and if it turns out
I'm wrong above and folks do want some such thing, I'll of course
try help get that done.)

Now, if we wanted to consider putting some equivalent to [1] through
the IETF consensus process then that would have a substantive effect
on IETF work and wouldn't just be something done for appearance's sake.
But that's a different day's work. That'd be more fun maybe, but also
more controversial I'm sure, and would probably take a while to get
right since we'd arguably need more clarity on the effects of having
much more ciphertext in the network. Anyway, I was thinking we might
want to start work on something like that after the MARNEW workshop
in September. [2] (And speaking of which: tomorrow's the deadline for
initial submissions for that workshop).

Cheers,
S.

[1]
https://www.iab.org/documents/correspondence-reports-documents/2014-2/iab-statement-on-internet-confidentiality/
[2] https://www.iab.org/activities/workshops/marnew/

---

From: Sam Hartman <[email-masked]>
Date: Mon, 13 Jul 2015 10:47:35 -0400

>>>>> "Carsten" == Carsten Bormann <[email-masked]> writes:

    >> I disagree. Publishing an update signals that our opinion has
    >> evolved.  It hasn't, even if the technology has evolved to make
    >> software the focus rather than hardware. Besides, this kind of
    >> document is a huge rathole, and I don't believe any minimal
    >> changes would be worth the hassle.

    Carsten> I completely agree.

    Carsten> Just as we elevated RFC 20 to STD, we could still elevate
    Carsten> it to BCP -- a status that, IIRC, was just becoming
    Carsten> available at the time RFC 1984 was published.

My only concern about RFC 1984 is that as far as I can tell it doesn't
represent consensus or policy.
It documents the sense of the room at one point in time.

I'm not sure that matters, but in terms of anything formal, an IESG
statement or BCP would have more formal weight as I read our processes.
If it happens that the community still agrees with RFC 1984, that formal
weight doesn't matter much.

I have found that when I use RFC 1984 as an argument that we should not
consider key recovery in design (and this has happened a few times over
the years) I do get pushback that it has no formal standing.

Truthfully though I'm not sure it matters much.  Those who favor key
recovery in a given instance can find some other explanation to justify
the technical tradeoff they prefer--generally in terms of permitting
helpful intermediates or the like.
All RFC 1984 does is change how we phrase our arguments, and I suspect
that will be true no matter how we revise it.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 13 Jul 2015 18:20:05 +0200

Hi Stephen,

> silliness, it does refer back to RFC 1984, as well as going further.

The reference to 1984 is in the IAB statement to demonstrate the
continuum of time that the IAB and IESG have considered this issue.  
There are some aspects of 1984 that could evolve.  Particularly the
rationale in the section entitled "PROTECTION OF THE EXISTING
INFRASTRUCTURE".  Encryption is required for there to be confidence in
the infrastructure.

> I'm wrong above and folks do want some such thing, I'll of course

I think Christian used the term "reaffirming".  Before we do that, we
people should really read through 1984 with a 2015 perspective.  The
document has held together well, even with a few issues.  But to
reaffirm would be to say that the 1996 world view is still applicable. 
I don't think it is.  I think we'd make a different statement today. 
Maybe this is what you mean by "renew".

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Jul 2015 13:43:09 -0400

> status that, IIRC, was just becoming available at the time RFC 1984 was

I agree that this is the right action.
Maybe it should be BCP1984 :-)

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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Jul 2015 12:38:09 -0700

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.

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.

On 7/12/2015 9:47 PM, Watson Ladd wrote:> On Sun, Jul 12, 2015 at 3:28
> The other factor is that we are entirely irrelevant to the
> discussion this time around.

The current issue is the advisability and effect on use of encryption
technologies, which are known to permit independent third parties to
compromise the encryption. For all of the politics of the topic, the
issue relies on technical matters. Technical matters about which the
IETF has some expertise.

There are a number of bodies that produce technical standards in this
space. The IETF is one of them. Having one or more of such bodies
produce statements concerning the technical, operational and usage
factors affecting this topic is entirely relevant, both to our own
choices going forward, and to the current public discussion now.

On 7/13/2015 6:28 AM, Stephen Farrell wrote:
> process, and while that doesn't directly touch on
> mandated-key-escrow- silliness, it does refer back to RFC 1984, as
> well as going further.

The IAB is not the IETF. No matter how august and diligent the IAB might
be, a statement from it is not at all equivalent to a consensus
statement from the IETF.

We often forget how essential that difference is, between an IAB
statement and an IETF consensus statement. As with others who have
posted, I think we shouldn't ignore it this time.

> On 7/13/15 3:28 PM, Stephen Farrell wrote: So I reckon that from a
> non-IETF perspective, [1] probably achieves as much as we'd achieve
> with any easy method of "renewing" RFC 1984.

That's a socio-political assessment and while it's easy to imagine that
Stephen is correct, it is equally easy to imagine that he is not. In
political terms, the sociopolitical difference between "a tiny body of
senior protocol designers" versus "consensus of a major international
technical standards body" could be quite significant.

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/

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 13 Jul 2015 21:02:00 +0100

On 13/07/15 20:38, Dave Crocker wrote:
> Stephen is correct, it is equally easy to imagine that he is not.

Actually it's easier to imagine I'm wrong, one way or another,
there being many more ways of being wrong, than of being correct:-)

But that's mostly why I tried to kick this off, since I'm not that
certain of my own conclusion on this.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 13 Jul 2015 21:11:05 +0100

Hiya,

> INFRASTRUCTURE".  Encryption is required for there to be confidence in

True, however, it's also true that the lack of mandatory key escrow
is also an inherent part of 1984 and my assumption at least is that
the IAB think the same and were cognizant of that in their statement.

> document has held together well, even with a few issues.  

Tend to agree. It's also addressing export of course but were any
of the recently mooted government silliness to become real, it'd
also have to involve controls on export/import as well as on usage
so that part of the analysis is actually still relevant I figure.
(There'd be an even bigger and even sillier impact on open source
the importance of which is nowadays probably better appreciated.)

> But to

TBH, I'm not sure what's meant by renew or re-affirming or anything
similar. So far, I think the suggestions made include an in-place
promotion to BCP, which I understand, or to do an update, meaning a
new RFC with revised content, which I also understand, and which
could aim for minimal or broader change. I don't get what or how
any other option might work out. Anyway, if we end up with consensus
to do something then I'm sure we can figure out the mechanics then.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 Jul 2015 14:20:22 +0100

Hiya,

> status that, IIRC, was just becoming available at the time RFC 1984 was

During the saag session in Prague we asked about this (more when I get
a chance to merge the good meeting notes we got). My conclusion from
that was that there seems to be a reasonable consensus among those who
were there and claimed to understand the issues to do as Carsten
suggests and there was almost no support for revising the text and
issuing a substantive update.

That means we try to upgrade RFC 1984 to BCP status in-place without
changes to the text or the RFC number.

I'm checking with the IESG and IAB to see if this plan causes them
angst and will report back in a week(ish) and take it from there. (So
get ready for, but please don't yet start, the potentially "fun"
process debate about the "C" in BCP - we'll undoubtedly do that in
an IETF last call;-)

Cheers,
S.