[saag] draft notes from SAAG IETF99

Joseph Lorenzo Hall <joe@cdt.org> Thu, 20 July 2017 13:12 UTC

Return-Path: <jhall@cdt.org>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3ECF1315FF for <saag@ietfa.amsl.com>; Thu, 20 Jul 2017 06:12:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyCKqJ12Bkpd for <saag@ietfa.amsl.com>; Thu, 20 Jul 2017 06:12:30 -0700 (PDT)
Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F48126E3A for <saag@ietf.org>; Thu, 20 Jul 2017 06:12:29 -0700 (PDT)
Received: by mail-ua0-x22a.google.com with SMTP id 80so22634782uas.0 for <saag@ietf.org>; Thu, 20 Jul 2017 06:12:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=Dyh3thmLYXgpFAs8Q/qAAOlghS4B6SBHcl1Se80ea0A=; b=kq59kwcigoMjPM53JGe0P3HLxvUAviWA3jv2upGGoOr6na6rphl/AR/SnPODR4ArwK /5zDYP6NU5gDjlpBH3RFtpyoHwPmJyU0uMVbRJcz2fpSWY6i4VkkS/RoTrN8QNySk6iN 4dpeUsOH1BBghiWqQyQQ5uksfYgvm6EzWeDYw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Dyh3thmLYXgpFAs8Q/qAAOlghS4B6SBHcl1Se80ea0A=; b=MjAucsWLqtAfDyLOCNJQ1zwVXijGXsiuuTpp6pAcWqrmx8xi+m5qgYxmJrfB0N4GG5 f0JKp0cTfPE/WnO0NtHnzZ0P46WiLdtT9fO4rOAeBWojFnkyqg57SYVf93OC/xZU7cFl m2M8elc/dfDMrWelkn6a8DmTz5iph7vwNxGtTv7ZNJ09MFHGwerDv96cDzPKJ2GinqSf dOWQQwqwvhRhx+vPNsBAu8uT8xiF6oitlj0Pe5Vc44dG9U0Q7pc/dJVCtLm/SR7/3lHI pdxip+COM9cXyPUrCSMMH2sMGtv4eYJzW3jbXBm2YLuXwaE6HxKhsobJJq7H93FYv8Ez ny0Q==
X-Gm-Message-State: AIVw1103YYC0llZED9ph/Nu6UADb/PVrJvCAt26JeCXDESc4AZseqEqc PC8JZTQAsrJCfbNBDEP9Q88dmzWPoCEJ7v/mOQ==
X-Received: by 10.176.82.212 with SMTP id w20mr2196424uaw.98.1500556348034; Thu, 20 Jul 2017 06:12:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.72.137 with HTTP; Thu, 20 Jul 2017 06:12:07 -0700 (PDT)
From: Joseph Lorenzo Hall <joe@cdt.org>
Date: Thu, 20 Jul 2017 15:12:07 +0200
Message-ID: <CABtrr-WUAw8wK3SzzJKROyBBdUmTpXc9vLaT+xJ1Zi0sd=YDBw@mail.gmail.com>
To: saag@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c18ee721724cc0554bf80fe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/RH3WbXx_LUMTJGWLazsNQcvbOKQ>
Subject: [saag] draft notes from SAAG IETF99
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jul 2017 13:12:33 -0000

 20-July-2017


   - Note Well
   - Working group reports
   -
      - ACE: (Hannes) met monday. lots of different proposals floating
      around about how to carry different documents around. Many researchers
      providing input. No much progress on charter items but lots of ideas.
      - I2NSF: (?) Met Thursday. Lots of contribs on data and info models.
      Make sure they are aligned, lots of good results.
      - OAUTH: (Hannes) Final session is tomorrow. In first session
      discussed wrapping up working group documents. Documented attacks agains
      JWD.
      - OpenPGP: (Barry) Remarkable success in getting anything done. It’s
      been difficult, and we’ve asked EKR to close the working group.
Sad that we
      could not get it done. (DKG) There is continuing work to get
that done. If
      they start submitting drafts, we may revisit it.
      - TOKBIND (Lief): Playing around with some documents.
   - Diameter E2E Security:
   -
      - Still looking for a solution for e2e in DIME here.
      - RFC7966 documents the e2e requirements.
      - We have reused a previous draft but there has been no progress.
      - Two new AVPs are defined for protecting other AVPs
      -
         - Are thinking of using CBOR/COSE or other alternatives.
      - Hop-to-hop provided by TLS but no e2e yet.
      - Jean Mahoney: Please help! Been pushed off and we can’t do this by
      ourselves
      - PHB: I have to generate something similar for mesh work. It’s
      written up but not separately but not pulled out. Willing to help.
   - Related working groups:
   -
      - DMARC: (Barry) Met this morning. Main thing that’s being discussed
      is whether or not to publish it (ARC spec) as experimental.
Crocker pointed
      out we don’t know if this will work. In our queue to move DMARC to
      standards track… unsure.
      - NTP: current draft is going to to to WGLC soon, security group was
      responsive.
      - DPRIVE: bunch of discsussion of DKG’s proposal to do demux over DNS
      on HTTP.
      - PERC: getting around some of the issues it had with double context
      encryption for RTP. Could benefit from folks when a new draft is out in a
      couple weeks. If you like crypto in real-time protocols.
      - RADext: going to close soon. Work on one more draft.
      - UTA: meeting later today. We can sort of start to see the light at
      the end of the tunnel. Got the core documents that we were
chartered to do
      in RFCs. If SAAG has other TLS application needs, let us know.
      - CURDLE for DKIM: three documents almost done. Deprecating RC4 and
      SHA1 for ED256.
      - PrivSec: traffic analysis draft.
      - IRTF open: checkoway talk on DUAL-EC-DRBG.
      - TEEP: tutorial on Sunday. Describe how it works, good attendance.
      Met Wed, to discuss charter.
      - FUD: firmware updates for IoT devices. had side meeting today. two
      new documents there.
      - Kathleen: we’re hoping to charter these last two soon.
      - W3C (Sam Weiler): WebAuthn making good progress. Trying to get more
      eyes doing privacy and security reviews on specs. Please get in
touch with
      me if you want to keep our WGs from doing stupid things.
   - Post-Quantum (Kenny Patterson)
   -
      - Lifetime of SHA1
      - Trade-off between SHA1 and SHA2 started in Apr 2016
      - Progress in Quantum Computing
      - The coming cryptapocalypse
      -
         - RLB: on the ECC point (that ECC will be broken earlier), is
         there a detailed analysis? A: Look for the name Tim Spiller.
         - Paul Hoffman: paper a few months ago said that ECC is probably
         stronger for the same strengths.
      - Ways forward - Post-Quantum Crypto
      - But what about Quantum Cryptography? (Kenny rains on our parade)
      - Punch line: we shouldn’t be too worried but we need to think about
      it.
      - RLB: What can IETF do?
      -
         - KP: comment on NIST process in terms of evaluation and the PQC
         process.
      - Paul Hoffman: current estimates for key sizes are going to be an
      order of mag larger… so like 50k-bit key sizes. If you have a
protocol like
      UDP where everything fits in one packet, you’re going to have a bad time.
      Paul has a draft (c2pq) at CFRG that basically asks what we
should do here
      at IETF/CFRG. We are going to want to know when we should start
working on
      this stuff.
      - PHB: 1) do have a degree in nuclear physics, QKD is probably not
      going to work given the engineering params. We do have Lamport
signatures,
      and might need to back them in now. 2) CAs started moving to
SHA-2 in 2008.
      The rest of the infrastructure wouldn’t accept them until much
later. As a
      CA, I can’t issue them if they don’t work.
      - Stephen Farrell: Comment: IETF could look at data items that might
      be sensitive in the future and then engineer to protect them.
      -
         - PK: not just the identifiers, but plaintext.
         - SF: had a nice timeline that said, sit back and relax for 7
         years. What’s the IPR situation look like?
         - PK: this is a good question. SHA-3 was a declare and
         royalty-free license. Will have to look.
      - Nick Sullivan: There are PQC schemes that can trade key sizes and
      computation to be more performant.
      -
         - PK: Comment about isogenies was that it’s so new.
      - Tobias G: with timelines I feel like I’m in a quantum state… we may
      only find out when the quantum state has collapsed. Protocols we design
      have lifetimes of 10 years +. Leads us to crypto-agility+ so that we can
      update them without breaking things in 5-10 times. Need to consider now.
   - Pretty Easy Privacy (Volker Birk)
   -
      - draft-birk-pep-00
      - from mic: (once it's time for questions): has the pep foundation
      ever taken a look at the work in UTA (WG) with regard to email security.
      reporting and UI/security improvements? AFAIK pep is just implementing a
      kind of overlay for popular clients based on either smime or gpg/pgpUTA
      meets later on, please join.
      - Paul Woters: not sure what you are suggesting. A new area in IETF,
      an effort.
      -
         - VB: there’s no central infrastructure, we don’t manage
         identities. Mapping identifiers into your own management of identities.
      - MT: read your draft, looked at your website. Neither of those
      things helped me understand what you are trying to do. Didn’t see an
      architecture or things that connect principles to your code. This is a
      massive project. There is a very big difference between implementing code
      and shipping code where you get interop.
      - PHB: I’ve been following this and I like it. ATM, there are a lot
      of useable secure messaging systems around. But they’re all single silo
      models. In order to talk to someone using Signal, I’ve got to get the
      Signal app. They’re all being sold as ways around government
providers. For
      anything to be secure, you’ll need documented standards or they can just
      coerce through the single point of failure of the sw.
   - Standardize Application-supported list of certificate limitation
   (Dimitri Belyavskiy)
   -
      - MT: is there a draft? I don’t know what this is. I certainly
      haven’t read this. You are describing something that has significant
      overlap with existing things. Why would this be superior?
      -
         - DB: The CRL can be issues by the application.
      - RB: there are application vendors doing this today. Google Chrome
      does CRLSets and Mozilla does OneCRL for Firefox. What’s the value in
      standardizing this and having so much more functionality.
      -
         - DB: want to provide a standard syntax.
      - DKG: Check out p11-glue. There is existing work that does this.
      - Rich Salz: OpenSSL hat on. It would be great to have something not
      just in browsers to do some of this stuff.
      - MT: as someone involved in one of the projects that has some of
      these things, we’d be willing to participate.
      - RLB: I can see there could be value to this. A soft prereq is going
      to be some notion of who is trusted to distribute this information. in
      Vendor/Application space this is clear. Not so true for OpenSSL or Debian.
      - EKR: (no AD hat) there are two problems to solve: 1) the policy
      problem of which anchors you trust and intermediaries you trust.; 2)
      distribution is hard and compression is necessary.
      -
         - DB: expect trust anchor being distributed with the application.
      - Open mic:
   -
      - Stephen Farrell: there was a bit of a fuss in TLS session. TLS
      would need to re-charter to do the draft-green work. Wondering what you
      guys think?
      -
         - KM: nothing has been adopted, still discussion, remains to be
         seen what will happen. Maybe there is an opp. for something
data-center
         specific.
         - SF: if they adopt something like this, do you consider that
         within their current charter.
         - KM: would need to re-read the charter. We’ll see what the WG
         ulitmately decide.
         - EKR: speaking not as AD, I don’t believe that draft-green would
         be within the charter.
      - Yaron: there was a Quantum Random Oracle mentioned in CFRG. Wanted
      to ask your personal opinion as to whether these models exist, are
      reliable, and are something that NIST can base their evaluation on.
      -
         - KP: yes, yes, and yes. Still getting around the QRO model.
      -








-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871