Re: [dane] Digest Algorithm Agility discussion

[Viktor Dukhovni <[e-mail]>]

On Mon, Mar 17, 2014 at 12:23:34PM -0700, Paul Hoffman wrote:

> Not correct. It allows local policy of any sort. Some local
> policies will be "do not use X because it is weak".

The language seems to suggest that refusing a digest by local policy
does not depend on the set of digests present in the server's TLSA
RRset.  If we are to fit my proposal into this "local policy"
framework, it would be to block all digests except the strongest
found for each usage/selector (thus depended on the RRset content).

Is such a local policy acceptable within the context of 6698.  Note
that in Postfix in addition to ignoring all but the "strongest", 
administrators get to simply ban some digests (which is how I read
6698) "local policy".

So my proposal does not contradict 6698 use of local policy to ban
digests, but it lifts the mandate to honour all the rest, and
replaces with a mandate to honour only the strongest remaining
digest from each (usage, selector) pair.

> > use of tarnished, but still acceptable digests even when untarnished
> > digests are present.  
> 
> It does not because that choice is local policy.

This boils down to how we define 6698 local policy.  My reading
was that one may decide to not support some digests, but nothing
quite as subtle as pruning the digests dynamically to just the
strongest presented by the server.

> > The new proposal is to ignore all but the
> > strongest, even when the remainder would be usable.
> 
> That new proposal mandates a view of "strongest". Local policy
> should still trump that mandate.

It does not specify which is strongest, that is deliberately local
policy.  It is also local policy which digests to not support even
when the server supports nothing better.

All it does is refine the 6698 loop to consider at most one (selected
by the client using whatever policy it likes) digest algorithm per
(usage, selector) combination.

> > Also the pseudo-code in the appendices loops over *all* "usable" TLSA
> > RRs (those not banned by 4.1).  
> 
> Correct. And RRs that are prohibited by local policy have already
> been removed:

Is it legal per 6698 to make the set of local policy removed RRs
depend on the set of RRs presented by the server?

If so, I am specifying a partial local policy, in which:

    - The set of outright banned digests is not fixed.
    - The preferences of the remaining digests are not fixed.
    - Once the client decides what to ban and the order of preferences,
      it bans all but the strongest TLSA RRs from the server.

> > My proposal modifies the pseudo-code
> > to loop over only those records (for each usage/selector) with the
> > strongest digest plus any records with matching type 0.
> 
> Over-riding local policy is a non-starter, at least in my opinion.

I don't see this as overriding local policy.  There is enough rope
in the choice of digests to ban and in the preference order of the
rest.  Those are my definitions of local policy.  Local policy can't
for example change the structure of the TLSA record, or the meaning
of SHA2-256, ...

If we fix a more precise algorithm agility protocol, that fixed part
ceases to be local policy, but that's OK, there is still local policy
for what is not fixed and it is quite sufficient for being able to
reject some algorithms and express preferences among the remainder.

> Also: your focus on digests is possibly misplaced; why do you
> believe that a digest is more likely to be tarnished than a
> signature algorithm itself?

I don't.  The TLSA record in 6698 employs multiple digest algorithms,
I'm specifying an agility protocol for TLSA digest algorithms.
Had 6698 specified multiple signature algorithms we'd be talking
about those.

-- 
	Viktor.