* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Dcrup Status Pages

DKIM Crypto Update (Active WG)
Art Area: Adam Roach, Alexey Melnikov, Ben Campbell | 2017-Apr-28 —  
Chairs
 
 


IETF-99 dcrup minutes

Session 2017-07-20 0930-1200: Berlin/Brussels - Audio stream - dcrup chatroom

Minutes

minutes-99-dcrup-01 minutes



          charter tweak - in flight
          John - hashing the key
              one open tech question:
              adding new signing ways
                  one is to do hashing of keys
                      straightforward to accomplish this
                  add elliptic curves ED25519
                  open question: should we add the hash for EDDSA sigs?
                      since there is no operational benefit, why do this?
              Martin Thomson - Potential benefit - by signing the public key in a
              header, it is possible in some situations to synthesize a key that
              will validate
              PHB - some games can be played with keys, has been a proponent of
              hashes, but don't think that they really provide benefit
                  need some tooling to manage the hashes
                  just wants to post the pub key into DNS
              Yoav - If we are trying to minimize the number of things that need to
              interop, do we need both hashing and elliptic curve?"  John - shrug.
              EKR - Martin's concern is key replacement in the zone
                  the most consistent thing in the future is to always hash,
                  but may not be critical
              MT - the future is bigger than the past
                  a little concerned about signing over the key, but general
              EKR - don't have two versions of EDDSA
                  pref order: hashed always/hash RSA only/non-hashed
              MT - post-quantum may require hashed keys regardless
                  Rich : please post concerns about key swap to the list
              PHB - may very well be looking at all standards to be revised in
              post-quantum world
              MT - note to the list about preferring hashing ratholed; don't miss
              the other points that were raised in flight
              EKR - names --> take it to the list
          
          Scott - dkim usage
              raise the floor to 1024, deprecate sha1
              updates ABNF
              pretty close to last call
          
              MT - concerns: PSS? don't do it here in the doc
                  why does it take 5 pages to do two simple things?
                  cut the text out which is copied from the DKIM RFC
                  don't modify the ABNF - point taken
              EKR - what are the security properties?
                  recapping sha1 attacks discussed on the list
                  when should we advise receivers to stop accepting sha1?
                      put into the security considerations: EKR accepted action
              need to move sha1 to historic in IANA - put into Scott's draft
              Barry - discussing "should (plus)" (from the room: don't go there)
              John - stopping acceptance is largely an operator evangelization issue
                  Kurt - having this draft in flight has been beneficial to getting
                  3 largest senders of SHA1 to change
              Chris - must check key size should be added
              MT - doc should just say "MUST NOT" (send or accept)
                  provides a good hammer to get change done
              PHB - objects to saying MUST NOT accept (only one in room)
                  for message validity yes, it matters
                  useful to follow appropriate phasing
              Seth - in 2007, sounded like "SHOULD NOT" - didn't move the needle
                  "MUST NOT" was needed to get people to move
              MT - want the headline
              Rich - timetable is important
              vendors hate "MUST NOT implement"
                  "MUST NOT use" is better
              andreas - should is justify to not change
          
              hums: for +++; against: +; need more info: barely
              Barry: did we just vote?
              Jim on jabber: too soon for MUST NOT accept
              Alexey - we got a sense of the room, but go to the list
          
          Scott Rose - doesn't think PC256 ECDSA is needed
              EDDSA should be sufficient when it gets into FIPS
              proposing to kill the doc
          
          



Generated from PyHt script /wg/dcrup/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -