Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest

From: Matt McCutchen <[email-masked]>
Date: Sun, 25 Sep 2011 20:28:59 -0700

On Sun, 2011-09-25 at 18:27 -0700, John Gilmore wrote:
> > No, a domain can do something very basic: for each cert, group all the
> > digests of that cert, rather than publishing a flat mishmash of digests.
> > This does not entail the domain assuming anything about the relative
> > strength of digest algorithms, yet it gives clients everything they need
> > to apply their own strength preferences.  Now do you get the point?
> 
> It's not clear to me what you mean by "group all the digests of that
> cert".  Group them how?  In the TLSA RRSET published by the domain
> owner?

Yes, see https://trac.tools.ietf.org/wg/dane/trac/ticket/22#comment:1
solutions 1 and 3.  Examples:

1. Each RR represents one cert and contains all the digests of that
cert:

_443._tcp.example.com TLSA 1 1 SHA-256 xxx SHA-512 yyy
_443._tcp.example.com TLSA 1 1 SHA-512 uuu SHA-3 www

3. Each cert has an ID number assigned by the admin, which serves to
cross-reference all RRs of that cert (which MUST have the same usage and
selector):

_443._tcp.example.com TLSA 0 1 1 SHA-256 xxx
_443._tcp.example.com TLSA 0 1 1 SHA-512 yyy
_443._tcp.example.com TLSA 1 1 1 SHA-512 uuu
_443._tcp.example.com TLSA 1 1 1 SHA-3 www

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Sun, 25 Sep 2011 21:07:25 -0700

> _443._tcp.example.com TLSA 1 1 1 SHA-3 www

I wanted to make sure everyone is clear on how I envision a
general-purpose TLS client using this information.  This is optional
behavior, out of scope of the spec; Paul Hoffman's client is welcome not
to do it.  Here is the procedure for method 1; the analogue for method 3
should be clear.

def DANE_Check(rrset, cert):
    for rr in rrset:
        A = strongest (per client preferences) digest algorithm in rr
        H = digest value for A in rr
        if A(cert) == H: return true
    return false

To illustrate that this achieves complete algorithm agility, consider
two clients:

(a) Supports A1 and A2, and believes that A2 is stronger than A1
(b) Supports only algorithm A1

And three servers:

(i)   _443._tcp.example.com TLSA 1 1 A1 xxx A2 yyy
Presented cert satisfies A1(cert) == xxx and A2(cert) == yyy.

- (a) checks A2(cert) == yyy, success (with the security of A2)
- (b) checks A1(cert) == xxx, success

(ii)  _443._tcp.example.com TLSA 1 1 A1 sss
      _443._tcp.example.com TLSA 1 1 A2 ttt
Presented cert satisfies A1(cert) == sss.

- (a) checks A1(cert) == sss, success
- (b) checks A1(cert) == sss, success

(iii) _443._tcp.example.com TLSA 1 1 A1 sss
Presented cert satisfies A1(cert) == sss.

- (a) checks A1(cert) == sss, success
- (b) checks A1(cert) == sss, success

Interoperability is maintained in all cases, and from the client's
perspective, the authentication is at least as strong as the strongest
algorithm fully supported by both sides.

-- 
Matt