Subject: [Dcrup] Notes from IETF99 dcrup meeting

From: Kurt Andersen <[email-masked]>
Date: Thu, 20 Jul 2017 11:21:38 +0200

(Apologies in advance for any names that I've mis-attributed)

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
    Ynir - why not just do curves and not hashing?
    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

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 20 Jul 2017 17:50:34 +0000

Kurt,

Thank you very very much for the detailed notes!

Attendees: please post corrections by next week!

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

From: Kurt Andersen [mailto:[email-masked]]
Sent: Thursday, July 20, 2017 11:22 AM
To: [email-masked]; [email-masked]
Subject: Notes from IETF99 dcrup meeting

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
    Ynir - why not just do curves and not hashing?
    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

        Kurt - having this draft in flight has been beneficial to getting 3 largest senders of SHA1 to change

---

From: Jim Fenton <[email-masked]>
Date: Fri, 21 Jul 2017 13:52:23 -0700

On 07/20/2017 10:50 AM, Salz, Rich wrote:
> *From:*Kurt Andersen [mailto:[email-masked]]
> *Sent:* Thursday, July 20, 2017 11:22 AM
> *To:* [email-masked]; [email-masked]
> *Subject:* Notes from IETF99 dcrup meeting
>
>  
>
>     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
>

Yoav was channeling me from Jabber here. The actual question was, "If we
are trying to minimize the number of things that need to interoperate,
do we need both hashing and elliptic curve? Aren't they two ways of
solving the same problem?" John's response was a shrug.

-Jim

>     MT - note to the list about preferring hashing ratholed; don't
> miss the other points that were raised in flight
>
>         Kurt - having this draft in flight has been beneficial to
> getting 3 largest senders of SHA1 to change 
>
> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Jul 2017 11:48:16 +1000

On 22 July 2017 at 06:52, Jim Fenton <[email-masked]> wrote:
> Yoav was channeling me from Jabber here. The actual question was, "If we are
> trying to minimize the number of things that need to interoperate, do we
> need both hashing and elliptic curve? Aren't they two ways of solving the
> same problem?" John's response was a shrug.

My understanding of this situation was that there was a desire to
provide an easy path for existing implementations where adding wholly
new cryptographic algorithms is not feasible.  That is, their existing
RSA signing/verification code could be used, just with larger keys and
a relatively small tweak to support hashing.

At the same time, performance for Ed25519 is considerably better on a
few dimensions.

Having two options (making three in total) does increase complexity
considerably, particularly since it is likely that all signatures
would need to be used to ensure that a signature could be accepted.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 31 Jul 2017 15:06:48 +0000

Kurt’s minutes have been uploaded, thanks!

From: Salz, Rich [mailto:[email-masked]]
Sent: Thursday, July 20, 2017 1:51 PM
To: Kurt Andersen <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: Notes from IETF99 dcrup meeting

Kurt,

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 31 Jul 2017 15:07:57 +0000

To clarify, Jim’s correction of Yoav’s jabber comment was included.