[Secdispatch] Additional Draft minutes from IETF-104

[=JeffH <[e-mail]>]

  > Security Dispatch (SECDISPATCH) WG Agenda
  > IETF 104
  >
  > Monday, March 25, 2019
  > 1350 - 1550, Afternoon Session I
  > Congress Hall 3
  >
  > (1) Logistics and introduction (chairs, 5 min)
  >
  > (2) Dispatch items
  > (Each item is 15 minutes)
  >
  > (2.1) Distributing OpenPGP Keys with Signed Keylist Subscriptions
  > draft: https://tools.ietf.org/html/draft-mccain-keylist
  > presenter: Miles McCain*
  > background: 
<https://mailarchive.ietf.org/arch/msg/secdispatch/3C0fhVxGoC3KUi6zKtinceJzqW8>

slides: 
<https://datatracker.ietf.org/meeting/104/materials/slides-104-secdispatch-distributing-openpgp-key-fingerprints-with-signed-keylist-subscriptions-draft-mccain-keylist-01>

https://tools.ietf.org/html/draft-mccain-keylist

ekr: keylist contains fp of public key and u said u can <what?>

dkg: this is a fp of your openpgp cert, rfc<48??>, u can update it 
without changing your fp

rbarnes: any need for hash agility here?
dkg: this draft is not correct place to address that, rather do that 
where opgp FPs are spec'd

benkaduk(bk): what about mult domains for the keys?  use "wkd" ?

micahl: <something about how non-scaleable the wkd stuff is?>

bk: are we claiming the sig from authnority key is authoritative for the 
neame and email address?

micahl(ml): what's signed here is entire PGP sig block, only required 
field is FP field...

dkg: this is innaresting soln, dont want to dive into details here, but 
I run a key server in this network, it is a disaster, it cant wishstand 
attack, if this draft depends on the keyserver netw, that needs to be 
re-considered, don't know how to dispatch this work...  thinks keyserver 
netw will not survive...

ml: gpgsync depands on keyserver netw, and that perhaps needs to be 
changed, not sure to what at this point....

chairs: we need to discuss keyserver issues it seems...

dkg: gpg keyrings might be a way to do this
ml: nominally agrees...

ekr: what does the signature actually represent?
ml: the purp of the signature on this keylist file prevents an atkr from 
putting an arbitrary list of public keys on folks' computers...

bk: it says 'these are keys ur innarested in of folks in your org...'


rbarnes: is this approp for AD sponsorship? (no one ran to mic)

    but first is this approp for doing in IETF? (no objections... no one 
runs to mic...)

    is anyone besides authors innarested in the work?  (4 or 5 hands)


leif johansson: there's subtleties here, ought to get careful review, 
things like this have been attempted in ietf before, so thinks it ought 
to be a good idea for a WG to look this more in depth, but realizes that 
may not happen...

Roman Danyliw(rd, co-chair): authors ought to continue to discuss on 
[e-mail] <mailto:[e-mail]>

ekr: as AD: yes, please continue to discuss on [e-mail] 
<mailto:[e-mail]>, and the authors bring it back to secdispatch 
when they feel it's ready for publication and we'll go from there


  > (2.2) JSON Canonicalization Scheme (JCS)
  > draft: 
https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme
  > presenter: Anders Rundgren
  > background: 
https://mailarchive.ietf.org/arch/msg/secdispatch/UHnVM_tzXh_s1WziznIiWVNSC4A

slides: 
<https://datatracker.ietf.org/meeting/104/materials/slides-104-dispatch-json-canonicalization-scheme-jcs-00>
draft: 
https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme

? cloudflare: ASN.1 should be (de)serializable, since that doesn't work 
round-trip, am skeptical that this would work...

Anders Rundgren(ar): slide 4 shows only known problem

matt miller(mm): this was discussed in ART Dispatch, there were 
questions, need to answer them...

yoav nir(yn): why we here in sec dispatch rather than art dispatch..?

ar: this is for sec protocols thus presenting here...

yn: yes this is just a bilding block for crypto protocols....

bret jordan: thinks this is worthwhile work, have tested some of the 
impls and they work, know of projects that could use this...

ekr: as individ: motivation seems weak, it is just readability afaict, 
canonicalization historiically has been a debacle, not desirable to have 
raw data and sig intermixed, thinks this is something we ought to not pursue

sean tuner: json is not really in ietf (cf ecma), there's history to 
that discussion, ask mm

mm: there was abs no consensus wrt json canonicalizatoin...

ar: see notes wrt above in the draft...

leif: thinks this approach is dangerous cuz folks may use the data 
before validating the signature

carsten: < not want to do in sec area? >

r barnes: as co-chair: ok, this is not SecDispatch work, pursue in ART 
Dispatch.





  > (2.3) MASQUE, obfuscating networking applications behind an HTTPS 
web server
  > draft: https://tools.ietf.org/html/draft-schinazi-masque
  > presenter: David Schinazi
  > background: 
<https://mailarchive.ietf.org/arch/msg/secdispatch/pG11oYDZTtH97iFebtQceXaSfS8>

slides: 
<https://datatracker.ietf.org/meeting/104/materials/slides-104-secdispatch-the-masque-protocol-draft-schinazi-masque-00>
draft:
https://tools.ietf.org/html/draft-schinazi-masque

martin thompson(mt): notes that there are lots of issues with this cf 
traffic analysis...big issue...

David Schinazi(ds): i'm asking for help on that...

dkg: yes, ietf has said "traffic analysis is outta scope" forever, lots 
of innaresting ideas here...

kathleen: <missed it>

rbarnes: dispatch outcome: this needs more work

benk: enuff folks here willing to join mailing list to discuss?

ds: ok, will ask for an ietf non-wg list...



  > (2.4) Security and Privacy Implications of Numeric Identifiers 
Employed in Network Protocols
  > draft: https://tools.ietf.org/html/draft-gont-predictable-numeric-ids
  > presenter: Fernando Gont
  > background: 
https://mailarchive.ietf.org/arch/msg/secdispatch/CXuvV5pW3Wik7Yl1fChZiNPkMwQ

slides: 
<https://datatracker.ietf.org/meeting/104/materials/slides-104-secdispatch-security-and-privacy-implications-of-numeric-identifiers-employed-in-network-protocols-draft-gont-predictable-numeric-ids-00>
draft: https://tools.ietf.org/html/draft-gont-predictable-numeric-ids

dkg: thinks this is innaresting as a bcp for protocol designers...

benK: have bcps for prot designers and not many know about them...

rd: co-chair as individ: wonder whether this ought to be in IRTF ?

ekr: wondering why not mission accomplished already cuz I-Ds live 
forever now?

watson ladd: wants an RFC

dkg: no draft expiration is a meta-meta discussion...

rd co-chair: generraly there's elements of interest in this, but no one 
saying we gotta make this an RFC...

dkg: well watson DID say I want an RFC I can point to in the next RFC I 
write!

rd co-chair: do we have any guidance on how to get there?  maybe SMART ?

watson: maybe CFRG?

rbarnes: priv RG?

dkg: RGs are often not expected to put restrictions on IETF RFCs...


Fernando Gont(fg):  proposing a BCP for a chunk of this for above reasons...

benk: trying to look into this earlier today, yes there's a bunch of 
info scattered here & yon, perhaps we pub a timeline to gathering it all 
togetther, initially...

rd co-chair: yeah, that...

sfarrell: if u wanna pub an RFC, do that, then it can be made a bcp 
later, cf rfc1984

benk: yeah, < one can do the above >, note that watson just needs an RFC 
to refer to as a normative ref...

rd co-chair: we'll try to help you sort this out in terms of publishing 
options...

fg: have heard that in the past, we want to make prog this time...



  > (2.5) Concise IDs and CBOR Certificates
  > drafts:
  > https://tools.ietf.org/html/draft-birkholz-core-coid
  > https://tools.ietf.org/html/draft-raza-ace-cbor-certificates
  > presenter: Carsten Bormann, John Mattsson
  > background: 
https://mailarchive.ietf.org/arch/msg/secdispatch/CGlf3NB2yhLyRgpyBpogPzi3CDQ
slides: 
<https://datatracker.ietf.org/meeting/104/materials/slides-104-secdispatch-concise-identities-draft-birkholz-core-coid-00>
draft: https://tools.ietf.org/html/draft-birkholz-core-coid

Carsten Bormann(cb): i'm talking about draft-birkholz-core-coid, jm 
(below) will be talking about something that seems similar but is 
different... I'm talking about "Profiling CWT for authenticated assertions"


John Mattsson(jm): talking about "Related Work, outside scope of CoIDs", 
ie Re-encoding X.509 certificates in CBOR 
(draft-raza-acecbor-certificates-01)
john's slides: "CBOR Certs" 
<https://datatracker.ietf.org/meeting/104/materials/slides-104-secdispatch-cbor-profile-of-x509-certificates-draft-raza-ace-cbor-certificates-01>


rd co-chair: pls goto mic if you want to help dispatch this...

ekr: hm x.509 started like 25yrs ago and look were we ended up... so, 
no, this needs to have its own WG

Giri M(gm): existing svc providers will want to not adopt something like 
this, and if IoT ends up using something like there, then need to define 
middlemen to convert btwn formats...

cb: this is sposed to solve probs where x509 does not work well, does 
not expect a need to gateways to spring up for this, jm's answer will be 
different...

jm: yes folks will convert btwn the formats...

?: do I just... <missed it>

sean turner: dont mess around -- just define a new format :)    dont be 
surprised you'll end up iwth a mess like the orig...

cb: if ur happy with x509, this work is not for u...

sfarrell: hard to do signif better than x509, good luck -- seems only 
advantage u have is encoding size...  pkix lasted 18+ yrs...

rbarnes: loves asn1, one can (de)serial round trip and end up iwth diff 
bytes (!)  8^)    how will this end up better?   also, there's work in 
TLS on cert compression, how is this better?

jm: yeah, need to do actual comparisons there, no clear answers yet, 
hear this is better but dont have proof presently

?1 (mic): knows of a national CA that wants this or something like it, 
so dont laff, ....

?2 (mic): certs are one thing in a PKI, there's lots of other 
datastructs in there too, are you going to update them all?

cb: well a signing req is just a CWT, so we can just reduce the # of 
variations we need...

coauthor of the cbor cert draft: question for sec cummunity: lots of 
examples of IoT folks who want to ship devices with certs, issues there, 
if u dont like these proposals, what do you propose?

rbarnes co-chair: this does not sound approp for secdispatch, seems to 
require a BoF



  > (3) Summary (chairs, 10 min)

impromptu addition: J. Hall (cdt): draft-hall-censorship-tech-07
   please review!!!


[saag] SECDISPATCH WG Summary from IETF 104
Roman Danyliw <[e-mail]> Mon, 25 March 2019 19:14 UTC
https://mailarchive.ietf.org/arch/msg/saag/v6QlgdtcoyIgI58eSCVB8d3fxMo

The SECDISPATCH WG met on Tuesday afternoon.  The agenda items were 
dispatched as follows:

(1) draft-mccain-keylist -- continue discussion on IETF OpenPGP mailing 
list ([e-mail]) to grow interest

(2) draft-rundgren-json-canonicalization-scheme -- not security area 
work; bring to ART

(3) draft-schinazi-masque -- needs more discussion; non-WG IETF mailing 
list will be created

(4) draft-gont-predictable-numeric-ids -- ADs will follow-up work to 
define right venue

(5) draft-birkholz-core-coid -- BOF recommended

(6) draft-raza-ace-cbor-certificates -- BOF recommended


end