Re: [Acme] Onion address validation extension

["Salz, Rich" <[e-mail]>]

We have time on the agenda, so I am going to add some open discussion time for this.

On 7/21/20, 6:45 AM, "Ilari Liusvaara" <[e-mail]> wrote:

    On Thu, Jul 09, 2020 at 09:01:25AM -0400, Ryan Sleevi wrote:
    > On Thu, Jul 9, 2020 at 8:30 AM Ilari Liusvaara <[e-mail]>
    > wrote:
    > 
    > > For designing a cleaner mechanism to propose to CABForum, I think
    > > reasonable starting point would be to model it like the ACME key-
    > > change endpoint.  However, signing JOSE messages with Tor key is
    > > not cryptographically kosher (just like singing CSRs with it is
    > > not kosher). However, again there should be no problems in practice
    > > (Tor itself never signs with this key, only derives other keys from
    > > it).
    > 
    > 
    > I think the odds of a change in the Forum are low here. I’ll readily admit,
    > I am intentionally rather hostile to JOSE / COSE being introduced into the
    > CABF, because of the consistent and persistent security failures these
    > formats lead to.
    > 
    > That said, given the rather significant improvements to the cryptographic
    > constructions of v3, I’m also quite keen for any establishment protocol in
    > the CSR that can suitably demonstrate a POP within the CSR. It needs to be
    > robust to cross-protocol reuse, but I suspect that is now substantially
    > easier given the v3 construction. I suspect that would also make it easier
    > for ACME, but perhaps I’m overlooking why even a simplified form is
    > challenging?

    It turns out that signing messages with Tor key does not have harmful
    cryptographic interactions with the way Tor uses that key (due to EdDSA
    also hashing the key when signing). 

    The main issue with the present CSR method is complexity. The applicant
    nonce does nothing useful (as due to ordering of the main EdDSA hash,
    R already strenghens it). The description of format is too hard to
    understand (an example would go long way to resolving the latter issue).

    There are simpler constrctions that would do the POP. For example
    (TLS syntax):

    struct {
    	opaque public_key[32];
    	opaque nonce<22..255>;
    } PopInner;

    Sign PopInner structure using TLS 1.3 signature format with context
    string "ACME, tor-rendv3-pop". Base64url-encode the 64-byte signature
    and send it in ready for challenge request. 

    CA can verify this by reconstructing the PoPInner from the known key
    nonce and verifying the given signature with the key.


    However, this does not do approval of ACME key (neither does the present
    CSR method). I think the reason of approving old key with new key in
    performing the key rollover is to prevent replaying new keys. Replay
    here is prevented by the CA nonce.


    And I think I found an issue in draft-shoemaker-acme-onion: It requires
    only 64 bits of entropy for CA nonce, while BRs require 112, and base
    ACME spec requires 128. Fix would be to change the first "64 bits of
    entropy" in section 4 to "128 bits of entropy". This is presumably due
    to confusing the two nonces, as applicant nonce can indeed be 64-bit.


    -Ilari

    _______________________________________________
    Acme mailing list
    [e-mail]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DwIGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=kBAk8JLDrgKC0IPKbyr4bCQAQ8pEZPcETi7Q0vjkUzA&s=xCkQ_STqxFwHRKntBP8xAnybPBYEL0JHJbkstYIyFIE&e=