[Swan] [perpass] my synopsis of the BoF session outcome (fwd)

[Paul Wouters]

Might be interesting to some.

Note especially that the homenet people have been awesome in defining
their standard access method to be "block all but IKE and ESP". They
really looked at good secure defaults!

Paul

---------- Forwarded message ----------
Date: Thu, 14 Nov 2013 09:45:33
From: Stephen Farrell <stephen.farrell at cs.tcd.ie>
To: perpass <perpass at ietf.org>
Subject: [perpass] my synopsis of the BoF session outcome


Hi all,

Here's what I took from the meeting notes and having
listened back to the recording. Overall, there was
a good bit more here that was concrete than I thought
was the case on the day, so thanks all for that!

I put the most vague first and the most concrete last.
Apologies in advance if I've annoyed you for how I've
characterised your valuable input:-)

As always, comments, discussion, volunteering are as
welcome as ever! Please start separate threads though
unless your follow-up is about the synopsis itself.

General thoughts/recommendations, some almost platitudinal:

- there's a tension between n/w mgmt & confid
- make middleboxes explicit
- write more code, connect with OSS communities
- think about how our code is implemented/operated, e.g. UPnP
- embedded ecosystem doesn't have updates, freezes in bugs,
   prevents deploying e.g. IPv6
- sometimes we get it wrong when we add too much security -
   e.g SIP wouldn't have been successful if we'd done
   security "right"
- successful crypto happens where the client just does it
   and doesn't have to ask, don't sacrifice usability
- better documented protocols have fewer security problems
- some protocols can't really be secured (e.g. DHCP) so
   shouldn't be used for lots of config stuff
- IPv6 + IPsec + RFC 6092 => IKE, ESP get in, could make
   things better?
- NAT is terrible:-)

Research topics, maybe for IAB w/s or IRTF?:

- it'd be good to have privacy metrics
- think through consequences of mitigations, there will
   be some
- if we get to OE, then how do we get from there to
   authentication when we want authentication
- problems handling security protocol failures (e.g. cert
   expiry)

Review stuff, hard to see such boring work being done:

- review old mouldy stuff (even in new docs), incl
   crypto uses
- e2e - maybe a survey of landscape is needed first?
- go look at why are existing protocols not being deployed?
- organised effort to privacy review existing protocols
   (directorate?)

Actionable maybe, nothing done yet:

- either find usable security folks to get involved or else
   make sure there's no UI, don't require large scale key mgmt
- maybe get servers (web) and CA people together to try
   develop some usable certification protocols
- same as above for DNS zone signing tools
- IETF should go beyond legislative definitions of personal
   data e.g. meta-data, define PII as privacy impacting
   information
- should we revise some security BCPs? which? how? who?
- (plenary) we should set the GAAP equivalent for
   security and privacy

Lots about OE, but quite actionable:

- define OE and how to do it - SF has asked someone if
   they'd write a HOWTO-pimp-my-protocol-with-OE draft,
   define it better and how to use it, and be careful with
   naming it to not imply you get more than you actually get
- OE: don't forget active attacks, they can also be somewhat
   pervasive
- OE: don't forget active attacks, they are worse attacks
- OE: don't forget active attacks, OE could be oversold
- OE: don't forget active attacks, they are more expensive
   and easier to detect
- OE: don't forget active attacks, cost increase may not be
   as good as you think, e.g. MITM to gather call records
- OE: don't forget active attacks, include ways to auto
   detect them (maybe after the fact)

Specific enough to have been actioned already:-)

- consider traffic analysis as part of protocol design
   (-> threat model?, asked Brian)
- define a "strong" RNG - a list has been setup for this
   that's, dsfjdssdfsd at ietf.org and has been announced
- reform privacy directive (asked, got 3-4 interested so
   far, not enough) if it happens, rfc6973 might help
   this time
   = got mail so far from:
       Scott Brim, Jim Fenton, Rhys Smith, Klass Wierenga
     more welcome
   = maybe include more, e.g. "privdir" review to be
     done when appsawg "adopts" or something?
- consider DNS confid, e.g. QNAMEs in DNS queries
   Bortzmeyer, Koch drafts, discussion with INT and OPS
   ADs ongoing for where to do that work

Regards,
S.
_______________________________________________
perpass mailing list
perpass at ietf.org
https://www.ietf.org/mailman/listinfo/perpass