Minutes IETF105: secdispatch
minutes-105-secdispatch-00

Security Dispatch (Secdispatch) WG Minutes
IETF 105

Monday 2019-07-22
Location: Place du Canada

Summary
=======
The following items were brought to the WG meeting and were dispatched
as follows:

(1) draft-richardson-lamps-rfc7030est-clarify-02 -- Dispatched to LAMPS
(2) draft-carrel-ipsecme-controller-ike-01 -- Further discussion is needed,
    especially to clarify the use cases
(3) draft-hallambaker-mesh-architecture -- Further discussion is needed.

Raw notes from Bret Jordan follow.

=====

Security Dispatch WG Meeting
IETF 105 - Montreal - Monday 2019-07-22
Location: Place du Canada

Chairs Present
Kathleen Moriarty
Richard Barnes

ADs Present
Benjamin Kaduk
Roman Danyliw

13:34 - Start Meeting

        • Logistics and introduction (chairs, 10 min)

Kathleen started the meeting
1st session will not follow normal format
No agenda bashing

(a) EST update (4 minutes present, 4 minutes discussion)
draft: draft-richardson-lamps-rfc7030est-clarify-02
presenter: Michael Richardson

Michael Richardson - RFC7530 extension, talked about Enrollment over Secure
Transport. About certificate enrollment. No one is using the content extension
header since it is deprecated by all the HTTP specifications.  No
implementations in the wild. Two of the issues raised by Sean Turner. A simple
clarification document. Transfer content-transfer-encoding is broken and this
document talks about how to deal with it.  Moving to binary is not a good
option since individuals like to use curl, so base64 is a better option. 
Trying to figure out where to send the document.  It needs an ASN.1 review

Martin Thomson - preference to send to existing working group.
Sean Turner - send to LAMPS. We should fix this thing. We could use the HTTP
accept header to try and tell the end devices what they accept. Michael, this
does not work for the POST Roman - Need a charter to send to lamps ? - Send to
lamps Martin Thomson - Talk about POST, Russ - pass the blues sheet

Decision from chairs: Dispatch to LAMPS

(b) Controller-IKE
draft:  https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-01
    Also some docs referencing this form of key management:
    BESS, Secure EVPN:
    https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-02 And:
    https://tools.ietf.org/html/draft-dunbar-bess-bgp-sdwan-usage-01
presenter: David Carrel

David Carrel
IKE is basically a Key management protocol that will work with a controller. A
diffi hellman exchange. Keep the scaling of the messaging down. The problem
they had is with large networks, 10,000 nodes in a mesh, there was too much
traffic.  Potential issues, is with rekeying and synchronization.  The draft
addresses the synchronization problem with a centralized controller.

This is not a replacement for IKE. It is not a 2-way attribution negotiation
protocol. In this model we are coming from a centralized controller.  Not
worried about negotiating desperate attributes.  We are not providing the
secure communication channel.  This is meant to be in some other communications
protocol.

Why. Optimization, reduced complexity and reduce messages from n^2 to n.  Orgs
want to have more control over managed networks.  Some links are not
bi-directional, but they can still talk to the controller. Other areas where
this is being discussed, I2NSF, BESS, IDR, RTGWG, etc.

There are two implementations of this draft.  The two drafts are highly
related. A lot of working groups are trying to integrate a controller based
design.

EKR - question about what is counted in the n^2 versus n. David - messages. EKR
- with this design you are not getting PFS.  An alternative design would be…
????  David - This is not the be all, in all, controller model.  EKR - You do
not want to do Peer 2 Peer, so what are you trying to save?  Michael Richardson
- is this for split brain controller????   Overall concerns about not using
Peer to Peer

???? - discussion about signaling.

Linda?? - Strongly support this proposal. When enterprises talking to cloud or
multiple clouds, there is lots of connections. Without this, the network is not
scalable.

???? - I2NSF has a similar solution, an IKE-less.  David - The I2NSF solution
requires that the controller knows all of the keys.  Which is obviously a
limitation.

David - The architectural model put forth in BESS

EKR - Not sure about the use cases and how it differs from other solutions

??? - This assumes your whole network is static.  Does not think every node in
the network needs to talk to every node. David - this work works really well in
dynamic networks.

Phil - This is not so much a key exchange but a message flow. I am interested
in this, and this is why. This looks very close to kerberos. This could be
viewed as a fail safe for quantum resistance.

??? - Performance improvements.  He would like to see data. Like to see
performance gains.

Alex - When you add a node, it talks to a central router….. low power, low end
nodes, do not have the capability of sending…  public keys

Danny - Some people say there are better way of doing this.

< missed a person >

???? - The controller has to dictate

Ben - Need more clarity for people in the room, is this an overlay network,
people in the room need more information.

Decision: Make requirements more clear.  It can stay in SecDispatch. Nothing
for now, revise and define requirements more clearly.

(c) Mathematical Mesh
draft: http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html

The following drafts are nearing completion:

http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html
http://mathmesh.com/Docume…/draft-hallambaker-mesh-dare.html
http://mathmesh.com/Docu…/draft-hallambaker-mesh-schema.html
http://mathmesh.com/Documents/draft-hallambaker-mesh-cryptography.html
presenter: Phil Hallam-Baker

Phil
Internet security is broken. Most of the breaches are on data at rest, but we
focus on transport.  Need more separation of duties.  Need more keys.  The Mesh
is a platform. People are not going to use PGP for email if they can not read
their email on every devices. We are still using the stuff from the blue book
not the red book.

It is a platform. Multi key platform. UDF uniform data format. We could add
this encryption key to a domain. This has multiple uses.  QR Code. All data in
the cloud is encrypted. Even if the cloud is breached, the cloud data is safe.
You can now do block chain like integrity or Merkel trees. Incremental
Encryption.

Applications.  Mesh Account belong to a user to a service.  You can use the
same tech for logs to help get to GDPR compliance.   This is almost a zero
trust model. I do not want to trust any key put in by a manufactures.  Some of
this was developed in the 1990s, but it was not part of the PGP cannon so it
did not get used. Designed to be end to end secure and abuse resistant.  It
does not prevent SPAM, but it makes it hard to make money with SPAM.  This can
expand multi factor.

Where do we go from here. Is this ready for the IETF.  If the IETF does not
want it, then it will need to go some where else. Once I start accepting users,
I will not want to make changes unless there is a real reason.

???? - Question on IPR.   Phil - There is a bunch of prior art that would
invalidate IPR claims. All of the code is MIT.  Phil is not aware of any IPR
issues.  You can use the use the mesh to distribute keys for SMIME and PGP.  
You could use this with open pgp, you do not change encryption at all, just
just decryption.

Martin Thomson - Thanks for bringing this here. If the IETF takes this on, this
is a major project.  It will take some time to get going.  How many other
implementers do you have working on this. Phil - none.

Phil - Do not wait until people adopt to read the drafts.

EKR - We are not replacing SSH, Phil, this is not about replacing SSH.  You can
use the mesh to distribute the SSH keys.

???? - You say this can help with IoT world.  Phil - the mesh network can help.
 You can avoid depending on cloud services.

Sean Turner - This does not seem like a good fit for the IETF unless you are
willing to make changes.  Phil, I am open to changes.

Rich - This seems like a large thing. Maybe if there was a smaller amount that
we could pull parts of the work out to work on.

??? - Take to some other place to work on

Bret  - Thank you for doing this, I fully support this work.

Roman - This is a big thing, we would need a BoF.

Phil - Part of the requirements for doing a BoF is to make sure you have people
aware of it, that is why I am here.

Kathleen - We should setup a list

Decision: Setup a mailing list and do a BoF

14:45 - End Meeting