Subject: Re: [saag] [Privsec-program] RFC3552bis...

From: Stephen Farrell <[email-masked]>
Date: Fri, 1 Jul 2016 15:48:48 +0100

(bcc'd the privsec programme, lets keep the discussion of this
on the saag list as we're talking about a BCP)

Hiya,

On 30/06/16 21:50, Fernando Gont wrote:
> On 06/30/2016 11:22 AM, Stephen Farrell wrote:
>>
>> - Kick off discussion now on the saag list (this mail)
>> - Get folks' feedback on changes they'd like (if that gets
>>   too voluminous we'll start a new list)
> 
> As could possibly be expected, we'd like to see additional requirements
> wrt transient numeric identifiers.
> 
> Please see: draft-gont-numeric-ids-sec-considerations-00
> (Security Considerations for Transient Numeric Identifiers Employed in
> Network Protocols)
> 
> In that respect, I wonder if, to keep the problem tractable, this could
> be worked out in draft-gont-numeric-ids-sec-considerations to have it
> formally update RFC3552, and then have the bis document pick up what we
> agreed on and incorporate it in the bis document.
> 
> FWIW, other wg's have followed this path for bis documents (e.g., TCPM's
> revision of RFC0793 (!)).

So I think what you're suggesting is that we develop a new RFC for
your stuff that becomes a part of BCP72 while at the same time we're
working on a bis for 3552 which would then replace both 3552 and
the new document with your stuff.

I don't see that makes much sense in this case TBH, unless you assume
that the 3552bis work will take years, which I hope won't be the case.

I think instead, we'd be better to roll any BCP-like statements (on
which we have consensus) from your stuff into a 3552bis and just
develop one new document. I think that's also likely to help us to
end up with something that's more readable/useful for the audience
too, rather than have a BCP with multiple RFCs. (*)

And to be clear, personally I do think that a 3552bis should make
the kind of statements about identifiers that your draft includes,
and I do hope that we'll reach consensus about those statements as
we go along.

Cheers,
S.

(*) For those less familiar with process minutiae, a BCP can consist
of more than one RFC, e.g. BCP9. [1]

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

> Thoughts?
> Thanks!
> Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 2 Jul 2016 14:56:18 +0200

Hi, Stephen,

> the new document with your stuff.

What I propose is:
1) Develop a new and shot RFC for the numeric identifiers stuff, that
formally updates RFC3552. Actually, we have publish that document
already, so I don't think there's much more to it than a round of
comments, and a WGLC.

2) In paralell, work on RFC3552bis, which eventuacally can incorporate
stuff from the above RFC. Eventually when 3553bis get published, it will
obsolete both RFC3552 and the above RFC.

I would expect at least one-year difference in the publication of #1 vs
#2. And having #1 published asap helps in at least two areas:

1) We don't keep publishing flawed RFCs or keep discussing flawed ideas
(see e.g. the 6man threads I've forwarded here)

2) This topic will not have to be discussed in the context of rfc3552
(since it will have already been discused while publication of rfc #1
above).

> that the 3552bis work will take years, which I hope won't be the case.

My experience with bis documents is that they take time. So, while I'd
like to believe that 3552bis will not take years, I'd bet that there
would be at least one-year difference between getting rfc3552 out and
getting a short bcp on numeric ids out.

> develop one new document.

Problem with that is that, meanwhile, such bcp (until published) doesn't
apply. I have invested/wasted cycles and cycles meanwhile on the topic
of numeric ids, which a bcp on numeric ids would have saved.

> I think that's also likely to help us to

FWIW, I don't want a bcp with multiple RFCs. When 3552bis gets
published, it can obsolete both rfc2552 and the bcp on numeric ids.

Thoughts?

Thanks!
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 2 Jul 2016 19:36:23 +0100

> Thoughts?

You've re-iterated what I thought you said. I'll not
re-iterate what I said :-)

Let's see what other opinions folks express, about this
specific point, but also (and IMO more importantly) about
the overall 3552bis plan and set of changes needed.

S.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 2 Jul 2016 20:45:10 +0200

> the overall 3552bis plan and set of changes needed.

A side question is how to proceed with the other two spin-off documents.

Essentially, one informational document which provides historical
perspective of how we've done in terms of transient numeric identifiers,
and another document possibly bcp or informational which contains the
different categories for the numeric identifiers, and possible
algorithms to generate them.

No matter how we proceed with the rfc3552 update, the question of how to
proceed with the other two documents remains. :-)

Thanks!

Cheers,

---

From: Programa STIC <[email-masked]>
Date: Sun, 3 Jul 2016 11:50:37 -0300

Hello

> the overall 3552bis plan and set of changes needed.

My opinion is that rather than try to get an all encompassing 3552bis by
collecting all the proposed changes to 3552 in a single long-winded
effort it would be easier, faster and more effective to break out the
process in manageable parts.

I'd rather see a process roughly like this:
1- Documents that update 3552 with guidance on specific topics are
discussed and eventually published
2- Once a number of documents in 1) have been published, they are
reviewed and a set is proposed to be collated for 3552bis
3- 3552bis results from the effort in 2) and ends up obsoleting those
from 1)

I do not know how many documents seek to update 3552 at the moment, I am
only aware of the I-D about predictable-ids that I co-authored. I
believe this discussion would be easier and more concrete if we had a
list of proposed changes to 3552 with the corresponding reference

regards,
-ivan

-- 
Programa de Seguridad en TIC
Fundación Dr. Manuel Sadosky
Av. Córdoba 744 Piso 5 Oficina I
TE/FAX: 4328-5164

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 3 Jul 2016 18:34:05 -0700

> > the overall 3552bis plan and set of changes needed.

I think the first step would be to rewrite the "Goal of security" section of
3552, to incorporate the "Goals of privacy." At that stage, we should have
the big Privacy related headers. Some of that is common with the currents
security topics, e.g. confidentiality. But some is not: linkability,
identifiers, etc. We should get a consensus on that before we start
formulating the actual guidance.

> A side question is how to proceed with the other two spin-off documents.

I don't think we have established a need for spin-off documents yet. Let's
have a principled approach, and start from establishing clear goals. I like
informative documents explaining the mistakes of the past or even listing
alternative algorithms, but we should refrain from publishing normative
documents before we have a good grasp on the goals.

In particular, we may want to revisit the thread on the ietf-privacy list,
"Is there an official working definition for Privacy Online?" 3552bis should
start by answering that question.

-- Christian Huitema

---

From: Watson Ladd <[email-masked]>
Date: Tue, 5 Jul 2016 22:04:58 -0700

> formulating the actual guidance.

And what privacy goals aren't contained within confidentiality? We're
still missing a ton of things people have learned over the past decade
in security such as:
-Formats write their own exploits: the more complex the grammar a
program accepts, the more likely the parser is wrong
-Configuration complexity is the #1 reason for poor configurations and
insecure protocols surviving
-You can't meet a goal you don't have: it's essential to think about
what needs to be protected
-Formal analysis of realistic cryptographic protocols is possible now
-Depreciation never happens
-Unexercised code is broken code

These considerations belong in any Security Considerations section.

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

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 6 Jul 2016 01:45:41 -0400 (EDT)

> And what privacy goals aren't contained within confidentiality? We're

At risk of being flippant, "all the metadata".  Cross-session
correlations, cross-protocol associations, you name it.

Not that I disagree with everything else you wrote, of course.

-Ben

---

From: Eliot Lear <[email-masked]>
Date: Wed, 6 Jul 2016 08:04:19 +0200

> formulating the actual guidance.

Yes, so long as privacy is clearly explained in a broad context.  A good
test of extremes might be a baby monitor versus an oil derrick.  At the
same time, the document should not become a 200 page tome that one must
master in order to produce a specification.

Eliot

---

From: Randy Bush <[email-masked]>
Date: Wed, 06 Jul 2016 21:00:57 +0900

> And what privacy goals aren't contained within confidentiality?

metadata such as traffic analysis

randy

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 6 Jul 2016 09:45:09 -0700

Couple of thoughts based on the experience with RFC 6973.

- The structure of RFC 6973 was highly influenced by RFC 3552. So integrating bits section-by-section wouldn’t be that hard for some sections (threat model, common issues). But this would likely not achieve the goal of making the document shorter.

- IIRC we had a goals section in early drafts of 6973 and ended up ditching it because we couldn't come up with something useful to say that people agreed about. Worth trying again though probably.

- RFC 6973 didn’t contemplate pervasive attackers. A 3552bis should.

Alissa

> On Jun 30, 2016, at 2:22 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
> RFC3552/BCP72 [1] is about to become a teenager:-) For those
> of you that don't know it by heart, that's the one that tells
> folks what to put into their security considerations sections
> and it dates back to July 2003.
> 
> Following on from discussion at saag in B-A, partly driven by
> the work Fernando and others have done on identifiers, but also
> other chats going back to the STRINT workshop, Kathleen and I
> have discussed what to do about all that and having re-read the
> text we reckon that now would be a good time to start work on
> an RFC3552bis document to replace the current one.
> 
> In outline, we think the main tasks there we'd like to see happen
> would be to a) update numerous things that are out of date, b) add
> text about things that weren't so important in 2003, such as privacy,
> perhaps borrowing bits from RFC6973 [2] that make sense as BCP-like
> statements, and c) to make it as understandable and easy to grasp
> as possible and ideally a good bit shorter.
> 
> Having figured out what we'd like, and being lazy ADs, we needed
> some other folks to do the actual work so we asked Yoav Nir and
> Magnus Westerlund (both cc'd) and we're delighted to say that
> they've agreed to be editors for this effort. (Thanks again to
> you both.)
> 
> The overall plan then is roughly to:-
> 
> - Have a short slot at the saag session in Berlin where the
>  editors can review the plan and get more feedback/comments
> - The editors will send some mail about tooling (e.g. if
>  they want to use github, they'll say that etc.)
> - The editors will produce a -00 and we'll iterate on that
>  until done
> - A more substantive discussion of remaining open issues
>  in November at IETF97 if needed, (which we suspect will
>  be needed:-)
> - Hopefully we end up ready for IETF LC around the end of
>  the year or early in 2017.
> - We have what'll quite probably be a fun IETF LC:-)
> - Mid-2017: BCP72 will become the new RFC.
> 
> So please do re-read [1,2] and send your comments on what you
> think needs changing to this list and/or the editors and/or to
> Kathleen or I as appropriate.
> 
> Cheers,
> S&K.
> 
> [1] https://tools.ietf.org/html/bcp72
> [2] https://tools.ietf.org/html/rfc6973
> 
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Jul 2016 13:15:29 -0400

Randy,

TA has been considered as part of confidentiality for about 30 years.

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 6 Jul 2016 13:58:07 -0700

> TA has been considered as part of confidentiality for about 30 years.

I am sure that defense against traffic analysis was considered by many
experts for many years. On the other hand, it obviously was not considered a
priority by IETF protocol designers for a long time. Documents like 3552bis
should correct that. Yes, we should say, "please care about
confidentiality." But we need to say a bit more, such as "do not spread
metadata all over the place." And it would be nice to give some broad
guidelines about the big categories that we care about.

-- Christian Huitema

---

From: Stephen Kent <[email-masked]>
Date: Thu, 14 Jul 2016 15:31:25 -0400

Christian,

> guidelines about the big categories that we care about.
I agree that more should be said. I was just noting that Randy's comment was
not quite correct in suggesting that TA concerns are not encompassed by 
"confidentiality".

Steve