Subject: [dane] Digest Algorithm Agility discussion

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 15 Mar 2014 05:17:04 +0000

The SMTP draft specifies a digest algorithm agility protocol for DANE.

In this thread it would be helpful to arrive at consensus around
the proposal, or a modified proposal if a better approach is
suggested.  Once that's settled, we can briefly touch on which document
is the right home for this protocol.

Goal:

    * It should be possible for servers to publish TLSA records
      employing multiple digest algorithms allowing clients to
      choose the best mutually supported digest.

Important barrier:

    * When two or more distinct objects (multiple certificates or multiple
      public keys) are published in TLSA records with multiple
      digest algorithms, it is not possible based on the TLSA records
      alone to partition the records by object instance, combining
      related records that are merely different digests of the same
      underlying object.

    * What this means is that clients can't tell whether ignoring all
      the records for a given weaker digest does not result in
      leaving out some objects which are only present with that
      digest.

Design:

     * The burden of making it safe to disregard records with deprecated or
       in any case less preferred digest algorithms is placed on the TLSA
       record publisher.

     * If for each given usage and selector, each published object that
       appears with a non-zero (i.e. a digest) matching type appears with
       the *same set* of digests as all other objects with that usage and
       selector, then it is definitely safe for clients to disregard all
       records except those with strongest (per client configuration)
       algorithm.

     * The server MUST employ this approach to publishing its records.

     * The client SHOULD employ digest algorithm agility by ignoring
       all but the strongest non-zero digest for each usage/selector
       combination.  Note, records with matching type zero play no
       role in digest algorithm agility.

Open issue:

     * Suppose the server records are clearly in violation of the
       requirement, because the number of records for one of the
       digest algorithms is strictly greater than the (non-zero)
       number of records for some other algorithm.

       Should the client apply the agility algorithm anyway (server
       is to blame if this is not safe)?  Or should it avoid using
       digest agility in this case?

       Note, avoiding the algorithm does not solve all possible
       problems.  The digest values could be mistranscribed, or
       even though the counts are the same, the sets of underlying
       objects for some pair of algorithms might still not be
       identical.

Larger question:

     * Is this the right agility protocol?  It seems to me to be
       roughly the best we can do given the structure of TLSA
       records.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Mar 2014 11:26:58 -0400 (EDT)

>      choose the best mutually supported digest.

Isn't that already possible?

>       role in digest algorithm agility.

I don't think that is a proper assumption. For example, a zone might
need to publish a GOST based digest for legal reasons (eg not trusting
US based digests) but might publish a FIPS approved digest for other
people. The client has a more complicated reduction scheme going on
for their local policy than "strongest".

Traditionally, for instance with the DS record, we allow publishing
multiple digests, and the client's task is just to find one which is
"acceptable". It would be nice if it starts with what it believes is
the "strongest".

If a certain digest is so weak it is basically broken, it should not be
left in a published TLSA record.

If the most prefered TLSA record fails validation, the client should try
another TLSA record. The order in which is does so could be written down
in the RFC if we think there is one true way of doing so.  Otherwise,
it should just be referenced in the RFC as "according to local policy".

This also gives the server admin some more protection. If they publish
digests using SHA2-256 and SHA1, and it turns out their tool generates
bad SHA2-256, than the clients still have a valid SHA1 to fall back to.

Perhaps there is text in the DS record RFC to look at that describes
this better than I just did.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Mar 2014 15:50:49 +0000

> Isn't that already possible?

Not based on RFC 6698 alone.  With RFC 6698 the client trusts all
TLSA records whether "weak" and "strong".

> for their local policy than "strongest".

I am not *assuming* anything.  We defined required client and server
behaviour which, if consistently applied by all parties, makes
algorithm agility possible.

The client decides which digest to use.  So long as the server
publishes each object (certificate or public key) with the same
set of digests as all other objects (i.e. the TLSA RRset is a "cross
product" of the desired objects and digest algorithms) no information
is lost when the client chooses just a single digest and ignores
the rest.

> "acceptable". It would be nice if it starts with what it believes is

My proposal is essentially the same.  The client uses the strongest
acceptable digest algorithm.  The *client* decides what "strongest"
means.  It never chooses an unsupported algorithm.

> left in a published TLSA record.

Weak digests (say SHA2-256 if/when broken) cannot be easily removed
from RRsets until all clients support stronger ones.  The idea is
to publish stronger digests and deploy stronger clients, then remove
weak digests later.  Stronger clients will never use the published
weak records.  Otherwise there's an Internet-wide flag-day.

> another TLSA record.

This works poorly.  While the weak algorithm is being phased out
(years) even clients that support stronger algorithms are at risk.

> The order in which is does so could be written down
> in the RFC if we think there is one true way of doing so.

The order is irrelevant.  Eventually some record matches.  It is
immaterial whether it is "first" or "last".

> bad SHA2-256, than the clients still have a valid SHA1 to fall back to.

They could also publish a bogus CU or selector, or mess up in many other
ways.  I don't think that the intent of multiple algorithms in 6698 is
to mask bogus data.

> this better than I just did.

Perhaps Wes can chime in.  His comment to me was that the proposed
DAA (digest algorithm agility) is essentially the only possible
and largely analogous to the DNSSEC approach.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 17 Mar 2014 09:47:46 -0700

This discussion comes up in every security WG. The proposal tries to help a client who wants to always use the strongest algorithm without actually having to understand why a different algorithm is weaker. This makes the semantics pretty intractable.

> TLSA records whether "weak" and "strong".

Can you point to the specific text for that? It was not my intention, and I doubt it was the intention of the WG.

> means.  It never chooses an unsupported algorithm.

Again, that was at least my intention for 6698. If we need to clarify that, that would be much better than adding another layer of protocol grease.

> weak digests later.  

Yes.

> Stronger clients will never use the published
> weak records.  

I strongly doubt that is the desired outcome. If so, lots of zones will go invisible when the "later" in "remove weak digests later" stretches to a decade.

Instead, a stronger client can have a setting that says "I'm going to abort when seeing a weaker digest, and I will alert you". The latter part is important.

> Otherwise there's an Internet-wide flag-day.

Which will never happen, so bringing it up is just hyperbole.

> (years) even clients that support stronger algorithms are at risk.

At risk of what? Seriously: DANE is additional security over non-TLS, so a "weak" algorithm is still better than "no TLS". Reduction to absurdity is not helpful here.

> and largely analogous to the DNSSEC approach.

I believe he is talking about RFC 6975. I do not believe that it attracted any significant interest.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Mar 2014 12:57:54 -0400 (EDT)

> TLSA records whether "weak" and "strong".

4.1 states:

       A TLSA RRSet whose DNSSEC validation state is secure MUST be used
       as a certificate association for TLS unless a local policy would
       prohibit the use of the specific certificate association in the
       secure TLSA RRSet.

Can that not be used to reject a weak digest?

> means.  It never chooses an unsupported algorithm.

but you want to fail if that one selected one fails. I don't think that
is the right decision.

> weak records.  Otherwise there's an Internet-wide flag-day.

I don't think we disagree. the server publishes a new strong digest, and
clients that support that and consider sha2-256 weak will not use
sha2-256. If the admin messes up the new strong digest, than new clients
will fail to get a TLSA record, and old clients will use an unsafe one.

> (years) even clients that support stronger algorithms are at risk.

New clients can have a local policy that states never to accept weak
digests. I don't see a problem with agility. The weak TLSA records
are only left in for clients that support nothing stronger.

> ways.  I don't think that the intent of multiple algorithms in 6698 is

Maybe I don't understand what you think the problem is?

> and largely analogous to the DNSSEC approach.

So aren't we all agreeing?

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Mar 2014 17:35:06 +0000

> Can that not be used to reject a weak digest?

The above proposal is for clients to black-list designated weak
digests, rather than select the strongest available digest.  If a
digest is not yet ready to be black-listed, but is no longer
recommended (as lets say SHA1 is now) we'd still have clients using
it even when stronger digests are published along-side.

I am proposing clients using *only* the strongest digest (as
determined by their configuration) and ignoring the rest.  This
results in a much clear phase-out process.  The weak digests are
only used when one of the sides only supports that digest.

It all boils down to how one might attempt to phase out a weak
digest.  If there is no "negotiation" (choice of strongest mutually
available option) transitions are much harder, because the weak
options are used until suddenly dropped, rather than gradually
becoming less common, until it is easy to phase them out because
almost nobody uses them.

> but you want to fail if that one selected one fails. I don't think that

There is no "right" or "wrong", only trade-offs.

> sha2-256.

The difference is that clients don't consider SHA2-256 (say) weak
right away, they initially get to prefer to not use it, whenever
(say) SHA2-512 is also published.

> If the admin messes up the new strong digest, than new clients

The admin messing up is a red-herring.  Nobody will publish two
digests just in case one is "messed-up".  They will publish multiple
digests to allow clients to choose the strongest one.

> are only left in for clients that support nothing stronger.

Such policy is difficult to enable, it applies even to servers that
only publish the weak digest.  My proposal incrementally phases out
the weak digest as servers publish the stronger version.

> Maybe I don't understand what you think the problem is?

Incremental transition from weak to strong algorithms with no flag
day (clients having to completely disable an algorithm to avoid
exposure to it even with servers that support a stronger one).

With TLS for example, clients don't have to disable all weaker
block ciphers, because the client and server will agree on the
strongest mutually available (based on either the client's or
server's preference list).  Once the mutually strongest option
is selected, the others are irrelevant.

The idea here is the same.

> So aren't we all agreeing?

Not yet.  To be specific suppose a server publishes:

	IN TLSA 3 1 2 {blob2}
	IN TLSA 3 1 1 {blob1}

and a client supports SHA2-512 (believed strong) and SHA2-256
(hypothetically tarnished, but not yet known broken).  In my proposal
the client completely ignores {blob1} *even if* {blob2} does not
match!  The client and server first agree on the strongest digest
(analogy with TLS cipher-suite negotiation) and then only that 
digest is used.  The same client authenticating a second server:

	IN TLSA 3 1 1 {blob3}

will use {blob3}.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Mar 2014 17:44:23 +0000

On Mon, Mar 17, 2014 at 09:47:46AM -0700, Paul Hoffman wrote:

> Can you point to the specific text for that? It was not my
> intention, and I doubt it was the intention of the WG.

Per RFC 6698, the client evaluats all "usable" TLSA records until
one matches, regardless of digest algorithm strength.

> Again, that was at least my intention for 6698. If we need to
> clarify that, that would be much better than adding another layer
> of protocol grease.

There is no text in 6698 that even approximately suggests that clients
get to use only the records with the strongest (local criteria) digest.

> > Stronger clients will never use the published weak records.  
> 
> I strongly doubt that is the desired outcome. If so, lots of
> zones will go invisible when the "later" in "remove weak digests
> later" stretches to a decade.

One can audit for weak TLSA RRsets on peer systems before deciding
to disable a weak algorithm.  My proposal makes it possible to
ramp security before completely disabling an algorithm.  Not doing
the proposed agility algorithm makes the problem worse.

> At risk of what? Seriously: DANE is additional security over
> non-TLS, so a "weak" algorithm is still better than "no TLS".
> Reduction to absurdity is not helpful here.

Of all people, I am quite surprised to see you say that.  DANE IS
NOT additional security over non-TLS.  DANE is a specification for
publishing public keys in DNS.  It can be used for both opportunistic
and non-opportunistic use-cases.  Postfix supports DANE in both
opportunistic and mandatory modes.

Please see also my reply to Paul W.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 17 Mar 2014 11:14:32 -0700

> one matches, regardless of digest algorithm strength.

Umm, I asked for specific text. :-) If it is in Section 4.1 (which is where it should be), I'm not seeing it.

> get to use only the records with the strongest (local criteria) digest.

In Section 4.1:
   o  A TLSA RRSet whose DNSSEC validation state is secure MUST be used
      as a certificate association for TLS unless a local policy would
      prohibit the use of the specific certificate association in the
      secure TLSA RRSet.
And at the end of Section 8:
   Generators of TLSA records should be aware that the client's full
   trust of a certificate association retrieved from a TLSA record may
   be a matter of local policy.  While such trust is limited to the
   specific domain name, protocol, and port for which the TLSA query was
   made, local policy may decline to accept the certificate (for reasons
   such as weak cryptography), as is also the case with PKIX trust
   anchors.

Crypto choice is definitely a local policy.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Mar 2014 18:22:19 +0000

>       prohibit the use of the specific certificate association in the

This is not "use strongest".  This is the opposite.  It forces the
use of tarnished, but still acceptable digests even when untarnished
digests are present.  The new proposal is to ignore all but the
strongest, even when the remainder would be usable.

Also the pseudo-code in the appendices loops over *all* "usable" TLSA
RRs (those not banned by 4.1).  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.

The key difference is the lifecycle of a tarnished digest.  With
6698, it is trusted until the moment it is dropped.  With the new
proposal it gradually fades out.  I think the fading out part is
an important feature.  It makes it possible to be secure with
servers that publish strong RRs even while accepting weak digests
from servers that don't.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Mar 2014 14:46:41 -0400 (EDT)

On Mon, 17 Mar 2014, Viktor Dukhovni wrote:

> RRs (those not banned by 4.1).

Okay, I understand your point now. The text in 6698 is indeed doing some
half weird local policy client dictation that it should not have done.

> My proposal modifies the pseudo-code

So I agree with you that is the right approach. I am not sure if I
agree that we should try and write that into an RFC other than
"according to local policy".

but the text should clearly not be like 6698, that would technically
violate the RFC if your method of local policy is implemented.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Mar 2014 19:00:28 +0000

> violate the RFC if your method of local policy is implemented.

The motivation to publish the proposed digest algorithm agility
algorithm is to encourage (coerce) server operators to make sure
that they always use "cross product" TLSA RRsets:

    for each usage
	for each selector(for that usage)
	    for each supported digest
		for each object (of given usage and selector)
		    publish usage selector mtype(digest) {digest(object)}

since the set of digests is the same for every object, it is safe
to ignore any subset of the non-zero mtypes.

Now this is in some sense already implied by 6698 since the server
operator does not know which digests might be excluded by a 6698
4.1 local policy.  The goal is to both highlight this requirement,
and to encourage (require) clients to implement agility rather than
leave it to implementor's imagination.

In Postfix, users get to configure which digests are acceptable
and their priority.  The default is to support both SHA2-256 and
SHA2-512 and to prefer the latter.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 17 Mar 2014 12:23:34 -0700

On Mar 17, 2014, at 11:22 AM, Viktor Dukhovni <[email-masked]> wrote:

> This is not "use strongest".  

Correct.

> This is the opposite.

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

>  It forces the
> digests are present.  

It does not because that choice is local policy.

> The new proposal is to ignore all but the

That new proposal mandates a view of "strongest". Local policy should still trump that mandate.

> RRs (those not banned by 4.1).  

Correct. And RRs that are prohibited by local policy have already been removed:
   for each R in TLSArecords {
     // unusable records include unknown certUsage, unknown
     // selectorType, unknown matchingType, erroneous RDATA, and
     // prohibited by local policy
     if (R is unusable) {
       remove R from TLSArecords
     }
   }

> strongest digest plus any records with matching type 0.

Over-riding local policy is a non-starter, at least in my opinion.

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?

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Mar 2014 20:25:31 +0000

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.

> 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.

> 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.

> Correct. And RRs that are prohibited by local policy have already

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.

> 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.

---

From: [email-masked] (Martin Rex)
Date: Mon, 17 Mar 2014 23:23:20 +0100 (CET)

> half weird local policy client dictation that it should not have done.

DANE does not have any "tarnished" hash algorithms.

DANE does not allow SHA1 at all and needs SHA-256 as a minimum.

The weakest "link" is therefore the hash that is used by DNSSEC
for the digital signature of the RRSET, which currently is SHA-1.

As long as DNSSEC does not require "stronger than SHA-256", it will
be pure bike-shedding to prefer a SHA-512 TLSA record over a SHA-256 one.

And you probably do not want to hold your breath until DNSSEC has
overcome SHA-1 based signatures.

The notion that hashes allowed by DANE can be ordered by strength/weakness
is also wrong.  In the future, hashes with the same output size might
get a codepoint assigned and used, and some of them might not be
implemented by all DANE clients.  Think of hashes from the russian
GOST family of algorithms.  Usage of SHA-512/256 over SHA-256 is not
motivated by algorithm strength concerns, but rather by raw hash throughput
considerations on 64-bit platforms.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Mar 2014 22:53:29 +0000

> DANE does not have any "tarnished" hash algorithms.

Not yet.  The point of algorithm agility is to plan for the future.
Yes, it is currently difficult to imagine practical weaknesses in
SHA2-256, but time marches on.

Yes.

> for the digital signature of the RRSET, which currently is SHA-1.

My zones are signed, or are about to be signed with algorithm 8,
RSASHA256.

> be pure bike-shedding to prefer a SHA-512 TLSA record over a SHA-256 one.

We're specifying an agility algorithm.  Nobody has to publish
SHA2-512 digests.  Only SHA2-256 is mandatory at this time.  When
SHA2-512 is published, it may as well be used in preference to
SHA2-256.

Getting the specification right from the start avoids problems
later.

> overcome SHA-1 based signatures.

There are existing zones that are signed with RSA, NSEC3, SHA256.

> is also wrong.

Nobody is suggesting ordering by the 8-bit mtype ordinal or mere
hash length.  The ordering is to be based on client-defined preference
for the underlying digest algorithms.

> In the future, hashes with the same output size might get a codepoint
> assigned and used, and some of them might not be implemented by all DANE
> clients.  

That's fine.  Servers can publish all mandatory to implement
algorithms, plus any others of their choice.

> Usage of SHA-512/256 over SHA-256 is not motivated by algorithm strength
> concerns, but rather by raw hash throughput considerations on 64-bit
> platforms.

And yet SHA2-512 likely has (absurdly) greater collision resistance
than SHA2-256.  Right now both are far out of reach of practical
attacks.  This may not always be the case, and, especially when
servers introduce various other hashes, clients may want to
use preferred digests.

I am not proposing anything particularly radical.  It is a fairly
obvious and conservative proposal.  "Negotiate" (pick from server's
menu of choices) an optimal digest algorithm and use only that one
and not the rest.

The objections are a bit surprising.  (I too would like to believe
that SHA2-256 will never be compromised, but it seems prudent to
plan for the worst).

To turn this around, why should clients run through all of the
server's published digests by default, when any one should be
enough?  Since servers don't know which algorithms clients disable
by local policy, it is a mistake to publish an object's digest with
only a subset of the algorithms used to publish other objects.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Mar 2014 22:26:47 +1100

This whole argument of weakest vs strongest was had years ago in
DNSSEC and quite frankly is a waste of time trying to pick the
strongest as you are often comparing apples and oranges.

DNSSEC validators just have a way to say "we no longer trust this
algorithm" and once that is set all records with that algorithm are
ignored when doing validation regardless of whether there is code
to support that algorithm or not.

DANE implementations need a way to do the same for matching type.

Stop trying to over engineer this.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 18 Mar 2014 14:13:56 +0000

> strongest as you are often comparing apples and oranges.

The client ranks the algorithms by preference, in much the same
way that TLS ranks cipher-suites by preference and in TLSv1.2 even
signature algorithms by preference.  It does not matter whether
the rankings are objectively justified.  The client uses its most
preferred digest (perhaps it has hardware support for it).

> to support that algorithm or not.

If things are as you describe, this works poorly, since clients
continue to accept weak signatures on zones that have both strong
and weak signatures (RSA/SHA1 and RSA/SHA256) if the strong signature
fails to match the client trusts the weak, right?

It becomes difficult to phase out a weak algorithm because the
incentive to publish the strong along with the weak is reduced
as the benefit from doing so is delayed until clients actually
discontinue the weak algorithm.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 18 Mar 2014 14:37:59 +0000

Thanks to everyone who contributed to this point.  My conclusions
so far:

    - Since "local policy" may exclude an arbitrary subset of the
      digest algorithms from consideration, whether the digest
      algorithm employed by clients is as I suggest, or not, server
      operators MUST apply the SAME set of digests to all objects
      published in a TLSA RRset, since otherwise the "visibility"
      of objects in the RRset will be client dependent.

    - Given the above clients either MAY or SHOULD apply the
      algorithm I propose, it provides incremental benefit before
      weaker algorithms are dropped, and reduces risks to servers
      that publish weaker algorithms.

      For example, with opportunistic TLS, client and server
      implementations can safely leave weaker cipher-suites at a
      low priority on their cipher-lists, because these will not be
      chosen when stronger options are available.  When nothing
      better is available, these are at least better than cleartext.

If "local policy" per 6698, includes the possibility of "adaptive
local policy" that depends on the server's TLSA RRset content, then
my proposal is already an implicit MAY per 6698.  I'd like to propose
to elevate it to a SHOULD, while emphasizing the MUST for the server
to publish cross-product TLSA RRsets when employing multiple digests.

Reminder: the proposal is that clients SHOULD apply some local
ranking to the digest algorithms, and only use those records for
each (usage, selector) combination that either have a matching type
of Full(0) or have the best ranking among all digests used with
that (usage, selector).  Clients SHOULD have a way to completely
disable algorithms.

-- 
	Viktor.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 18 Mar 2014 10:38:22 -0700

> -----Original Message-----
> From: dane [mailto:[email-masked]] On Behalf Of Mark Andrews
> Sent: Tuesday, March 18, 2014 4:27 AM
> To: [email-masked]
> Subject: Re: [dane] Digest Algorithm Agility discussion
> 
> 
> This whole argument of weakest vs strongest was had years ago in DNSSEC
and
> quite frankly is a waste of time trying to pick the strongest as you are
often
> comparing apples and oranges.
> 
algorithm"
> and once that is set all records with that algorithm are ignored when
doing
> validation regardless of whether there is code to support that algorithm
or
> not.

+1 - At any given time this is a binary choice.  The hash algorithm either
is or is not acceptable.

Jim

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 18 Mar 2014 11:09:31 -0700

>      of objects in the RRset will be client dependent.

This discussion keeps getting into the "we're the Internet Police" realm. First it is "we know which hash algorithms are too weak", and now it is "operators must do this action or else different clients will behave differently".

If an operator wants to use a particular hash algorithm *for any reason*, we should not stop them.

>      better is available, these are at least better than cleartext.

It would only have that benefit if there was agreement from above on what "weaker" was and whether we should force people to limit themselves to our algorithms.

> my proposal is already an implicit MAY per 6698.  

Exactly right.

> I'd like to propose

This is insane. You are creating operational failure cases for servers for no benefit until one of the hash algorithms has a significant weakness. Even then, the damage you are proposing quite outweighs the chance of any real damage from the use of a weakened hash. Hashes weaken very slowly, and there is plenty of time to alert people to use stronger hashes.

> that (usage, selector).  Clients SHOULD have a way to completely

They do: it's called local policy.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 18 Mar 2014 15:20:07 -0400

> If an operator wants to use a particular hash algorithm *for any reason*, we should not stop them.

I would say this instead as, "We will not be able to stop them anyway,
so we should focus on interoperability and maybe some sound advice,"
but I know lots of people will disagree.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 18 Mar 2014 20:00:04 +0000

On Tue, Mar 18, 2014 at 11:09:31AM -0700, Paul Hoffman wrote:

> [ Lots of misinterpretation and inaccuracies about the proposed mechanism. ]
>
> This is insane. You are creating operational failure cases for servers
> for no benefit until one of the hash algorithms has a significant weakness.
> Even then, the damage you are proposing quite outweighs the chance of any
> real damage from the use of a weakened hash. Hashes weaken very slowly,
> and there is plenty of time to alert people to use stronger hashes.

> +1 - At any given time this is a binary choice.  The hash algorithm either

I don't think I to need to restate the merits of the incremental
security as stronger digests are added before weaker ones are
disabled.

My sense is that regardless, there is not much enthusias for
negotiating a single digest based on what digests the server offers,
with the client choosing its most preferred one.

Is this an accurate summary of the group's consensus view?  Does
anyone want to defend the view of TLSA digests as a menu of options
from which the client can choose one?

If not, I will drop the digest agility portion of the SMTP draft.
In the OPs draft we can encourage server operators (SHOULD) to
apply all digests equally to all objects, because that's more robust
in the face of local policy, and results when this is not done may
not be what the operator wanted.

Anyone else?

-- 
	Viktor.

---

From: Scott Rose <[email-masked]>
Date: Wed, 19 Mar 2014 10:08:38 -0400

> from which the client can choose one?
Don't know about the rest of the WG, but it's mine.  Some communities have a larger local policy that they want to enforce, and the client will prefer that primarily, with potential fallbacks. 

> not be what the operator wanted.

Still need to see the final text, but looks like it is the right direction.

Scott

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 19 Mar 2014 14:35:27 +0000

On Wed, Mar 19, 2014 at 10:08:38AM -0400, Scott Rose wrote:

> Don't know about the rest of the WG, but it's mine.  Some communities have
> a larger local policy that they want to enforce, and the client will prefer
> that primarily, with potential fallbacks.

Sorry, could you confirm the meaning of the above sentence?  Probably
my fault, but I am not 100% sure whether you're saying that clients:

    - should (proposed agility protocol)
    - may (employ adaptive local policy that amounts to the above), or
    - must not

ignore lesser ranked (by the client's local policy) digest matching
types in the server's TLSA RRset.

> Still need to see the final text, but looks like it is the right direction.

This seems to suggest a vote for either "may" or "must not" above...

-- 
	Viktor.

---

From: Scott Rose <[email-masked]>
Date: Wed, 19 Mar 2014 10:51:39 -0400

>    - may (employ adaptive local policy that amounts to the above), or

The document should drop the algorithm agility text.  RFC 6698 is enough IMHO.   

Scott

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 20 Mar 2014 15:12:23 -0700

> The SMTP draft specifies a digest algorithm agility protocol for DANE.

So, trying to review this thread for where things stood and a number of
things jumped out at me.  Specifically, there is a lot of violent
agreement on some things.  So let me get the most important out of the
way that I'm firmly convinced everyone agrees on:  local policy always
trumps everything.  EG this is perfectly acceptable:

   if moon == full:
      acceptable_alg_list = [GOST]
   else if elvis == reborn or the_beetles == on_tour:
      acceptable_alg_list = [MD5, SHA51]
      prefer = any_match
   else 
      acceptable_alg_list = [SHA512, SHA256]
      prefer = first_existing_alg_published_from_list

And that (wacky) policy would always trump any other decision tree in
the code base.

Where things have been falling apart are

   o 
   o What is the default for "prefer", any_match [most people's opinion] or
     first_existing_alg_published_from_list [Viktor's opinion]?

To really consider this, we have to take a few things into account:

   o The server is unable to publish, for their clients, their
     preference order.  There is no way to make the statement "please
     authenticate my certificate using SHA256.  Unless you don't
     understand it, in which case just use SHA1".  The *only* thing it
     can do is publish things it trusts and hope the client uses the
     best one available, for which it has no say.

   o The client gets to pick what it's willing to accept and what it's not.

   o But, there are two sides to DANE.

     1. DANE is augmented security to the base infrastructure.  Rather
        than allowing 1300+ X.509 CAs, it restricts the connection to a
        single, linear X.509 path (tied to a single, linear DNSSEC
        path).  This is certainly the case for the HTTP case.  Even a
        MD5 hash to double check the CA path is likely an improvement
        to the non-DANE case.  It's an *added* check to the existing
        infrastructure.  So clients are more likely to be willing to
        accept nearly anything "not broken".

     2. DANE is *the* security mechanism, and without it you simply
        can't do some aspect of security.  In the SMTP case, it is
        impossible to do authentication without a DNSSEC/DANE solution.
        6698 was not originally written to cover this case (and, as
        discussed recently, this all hinges on "discovery" and that was
        deliberately left out of past solutions).  In this case, it's
        much more likely someone may want a policy of "if they indicated
        they can do my most preferred algorithm, then don't transmit the
        message if that algorithm is failing.  I don't care if there is
        another match to a less preferred one.

    o Now for case #2, it'd be easy to simply thing "look, just don't
      specify MD5 if you don't trust it".  But that's not so simple when
      it comes to connecting to random machines in the world.  It'd be
      great to have a policy of "Only accept SHA256 from example.com,
      but accept either SHA256 or SHA512 from example.org if either
      works".  That that's not a manageable policy to maintain for the
      internet at large.

      So where does that leave us?  With a choice.  What do we want as a
      policy knob.

The choice:

   Do you, Mr. System Administrator defining the local policy for the
   *client*, want:

   A) Accept any published hashing algorithm out of my "unordered set"
      to validate the remotely presented certificate.  [Ordering it
      doesn't buy you anything since you'll simply accept a match and it
      doesn't matter which you try first, since any success in any
      algorithm will equally indicate "ok"; in fact in an implementation
      aiming for speed, it might be best to choose the order based on
      how fast you can execute the algorithm].  If the server fails to
      publish a perfect record set, as long as one matches I'm ok with that.

   B) Believe that the server will always publish perfect records, and
      if my "ordered set" of algorithms is [SHA512, SHA256] and they
      publish SHA512, then I never want to accept SHA256 because I fear
      an attack more than I fear a server administrator blowing their
      configuration.

So to recap, first: either of those is fine in local policy knob setting
scheme.  Implementations can let administrators of clients configure
sane or insane policies they want.

But the real question, is what is the *default* that we should suggest
an implementation do?

RFC6698 indicates choice A ("accept anything that matches in my
unordered set").  But, what about other specific protocols?

I) what should we do generically?  RFC6698 already laid this out as A in
   absence of local policy.

II) what should we do in SMTP?  This is where Viktor, considering case
    #2 above, is wanting to do B ("accept just the 'best' in an ordered set
    of algorithms) instead of A.  The arguments, though, from both sides
    are probably talking about different cases (generic vs SMTP) and I
    think that is ending up with some of the confusion.

Here's the multiple choice quiz to cap all this off:

1. For generic DANE, is the right *default* choice:

   A) Accept any successful matching hash, regardless of "strength".
      (This is what 6698 says to do today)

   B) Accept only the strongest hash, from an ordered list, that the
      server has published (and DNSSEC has validated the RRSET for).

2. For SMTP, is the right (SMTP-application-specific) *default* choice:

   A) Accept any successful matching hash, regardless of "strength".
      (This is what 6698 says to do today)

   B) Accept only the strongest hash, from an ordered list, that the
      server has published (and DNSSEC has validated the RRSET for).

3. For XMPP:

   A) Accept any successful matching hash, regardless of "strength".
      (This is what 6698 says to do today)

   B) Accept only the strongest hash, from an ordered list, that the
      server has published (and DNSSEC has validated the RRSET for).

4. For HTTP:

   A) Accept any successful matching hash, regardless of "strength".
      (This is what 6698 says to do today)

   B) Accept only the strongest hash, from an ordered list, that the
      server has published (and DNSSEC has validated the RRSET for).

5. For IMAP:
....

-- 
Wes Hardaker
Parsons

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 21 Mar 2014 01:07:56 +0000

[ Forwarded on behalf of: Phil Pennock <[email-masked]> ]

> trumps everything.  EG this is perfectly acceptable:
[...]

Yes.

(I apologise in advance for how long some of what follows is.)

>      first_existing_alg_published_from_list [Viktor's opinion]?

It's also my opinion [see next paragraph], speaking with my Exim
Developer hat on; alas, ietf.org tends to blackhole my mails, making
it rather hard for me to participate.  I'd rather not start using
a Gmail account just to be able to participate in an IETF discussion,
but currently I've left the impression that Viktor is rather alone
in his current stance, which is deeply unfortunate.  (If this mail
doesn't make it through, perhaps a named recipient can forward it
on again?) 		[ done: Viktor. ]

I think Viktor's opinion is more accurately stated as
"first_existing_alg_published_by_remote_found_in_local_list"; a
distinction which emphasizes that it's not central control of
algorithms but is instead local control.  The issues are around
ensuring that default policies are not wacky and SMTP interop can
avoid breakage and flag-days.

The problem that I see is that the history of SMTP shows that if
we leave a lot of ambiguity, people will do some very strange
things, even in areas which aren't so security sensitive; further,
strange things now have the ability to hinder algorithm agility in
the future.  So this is not bike-shedding, but is instead trying
to provide solid guidance to implementers about what is most likely
to provide a solid interoperable solution which doesn't leave us
with a lot of unable-to-migrate systems come the day that a practical
second pre-image attack is announced against something in the SHA2
family.  And please let's not descend into debate about how likely
that might be -- the point is to help ensure that security features
added now don't needlessly repeat the mistakes of the past.

So, whichever path is chosen, "any match" or "first match from your
local policy of whichever algs you trust", the spec needs to provide
clear guidance so that most MTAs implementing DANE will end up
using similar logic.

>       an attack more than I fear a server administrator blowing their

The issue is around the time period where there is a widely accepted
but then-known-to-be-broken hash algorithm (with a hope that it
will become less widely accepted) and another algorithm, at that
point in the future then-currently believed to be safe, and what
are the effects which will speed or hinder a safe orderly transition
to the use of the second algorithm.

A separate issue (which doesn't need to hold up this specification)
is letting the recipient system know what the impact would be of
dropping the old algorithm from the published set.  Tony Finch's
"Transmitted:" trace header from the draft-fanf-dane-smtp series
would help here and it's easy to see how this can build on top of
the current work (and does not need to be part of the current work).
I'll assume Transmitted:  below as shorthand for "or anything
equivalent" (eg, RCPT parameter stating for each recipient how the
client decided this was the correct server, etc etc).

If there is a clearly defined "you should prefer the algorithm
which you trust the most, when selecting a TLSA anchor from the
set I publish", and later an ability for a server operator to get
stats on which anchor the client used, then the server operator
can get metrics on which keys are actually used and what the impact
of withdrawing the publishing of the old key would be.

With the "accept any" approach, the only solution is to stop publishing
one day, 15 years after the point when anyone sane would have switched,
and discover from the howls of protest the few organisations who are
horribly broken.

I'd much rather see a designed in decay-curve in the use of the
known-broken algorithm, an ability for a future Transmitted: header
to be meaningful, a rational basis for recipient postmasters to be
able to say "If you cared, you should have told us which was in
use with the Transmitted: header.  You didn't tell us, and everyone
else stopped using it, so we stopped publishing the data which
~everyone thinks is worthless and dangerous if relied upon."

> sane or insane policies they want.

The client side can do whatever it wants, but if it expects to be
able to _stay_ secure in the face of ongoing crypto research and
not cause every postmaster to curse the idiot vendor, it should
use the "have a preferred list and find the first in our list which
the remote site published" approach as the default (absent prior
site-specific negotiation).

> I) what should we do generically?  RFC6698 already laid this out as A in

That's effectively a punt on algorithm agility and disappointing.

>     think that is ending up with some of the confusion.

So Viktor and I, representing Postfix and Exim, both want this.

>       server has published (and DNSSEC has validated the RRSET for).

C) Accept the strongest hash, from an ordered list maintained by the
   client, of those hashes published by the server (as confirmed by
   DNSSEC yada yada).

(This might be B, but your B is still not unambiguously worded, sorry.)

I'm only going to push back on those app-specific protocols where
I'm an implementer and my code talks, since otherwise I'm making
mandates of other people.

>       server has published (and DNSSEC has validated the RRSET for).

C above.  A perhaps implemented but needing explicit action to
activate, as a "bug compatibility workaround" for remote sites.

> 5. For IMAP:

No voice, am not an implementer, but I'll cough "C" if people are
willing to listen.

More generally: approach A can't distinguish between "successful
attack on hash" and "remote site bungled".  In the event of a
mishap, mail queues and postmasters investigate, nothing is lost.
This sort of thing happens routinely today (see, eg, mailops mailing
list, whenever some big site suddenly starts deferring a lot of
mail).  People notice.  Out-of-band mechanisms are found.

Codifying a solution of "thou shalt be vulnerable to the worst hash
algorithm you publish, because the clients should accept it as
sufficient" is cause for those who care about privacy of incoming
mail to stop publishing the hash fast, which breaks verification
if clients don't have an alternative.  Instead we want a model
where operators can allow for migration which always has a trust
path, knowing that continuing to publish known-broken only affects
integrity of the path for those senders who either only support,
or prefer, the known-broken hash algorithm and that everyone _else_
immediately gets the benefit of other published hash algorithms.

So, since we're still at the stage where we can avoid going wrong
instead of having to try to figure out compatible ways to recover
later, can we *please* codify that the default approach should
support algorithm agility instead of vulnerability-to-worst-published?
Queuing happens, mistakes will get caught with no worst problem
than some delayed email, which I argue is far more in keeping with
common expectation than "your mail will go through quickly, but we
might have sent it onto some attackers, we don't know".

-Phil, [email-masked]

---

From: Peter Palfrader <[email-masked]>
Date: Sat, 22 Mar 2014 08:47:37 +0100

>     think that is ending up with some of the confusion.

I'd like to see the SMTP draft suggest B.  (All the others should do B
too, but that's a different story).

Aloha,
-- 
                           |  .''`.       ** Debian **
      Peter Palfrader      | : :' :      The  universal
 http://www.palfrader.org/ | `. `'      Operating System
                           |   `-    http://www.debian.org/

---

From: Mark Andrews <[email-masked]>
Date: Mon, 24 Mar 2014 04:42:05 +1100

> too, but that's a different story).

Truly, we do not know which of SHA256 and SHA512 will be broken
first.  Both are more than strong enough for this job at this point
in time.  When one is broken it will no longer be strong enough.
Neither will be broken by brute force.  They will be broken by
discoveries of flaws in the algorithms.  We support multiple
algorithms so that when/if one is broken we do not end up in a
situation of having no trusted algorithms supported.

Mark

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 23 Mar 2014 18:21:07 +0000

On Mon, Mar 24, 2014 at 04:42:05AM +1100, Mark Andrews wrote:

> in time.

Agree with this 100%.

> When one is broken it will no longer be strong enough.

I assume that once the SHA3 (aka Keccac) specification is finally
published by NIST, there will be a DANE-related draft registering
at least two new matching type algorithms for TLSA records:

    3	SHA3-256
    4	SHA3-512

At that point, a client evaluating a TLSA RRset will have a real
choice, for example: SHA2-256 vs. SHA3-256.

The reason the SHA3 competition was held and the Keccac sponge
construction was selected, is that with MD5 and SHA1 looking broken
and vulnerable respectively, there was a desire to find new hash
primitives that are based on new ideas.

So SHA3 is essentially our insurance policy on further progress
against the similar SHA1 and SHA2 designs.  While for now progress
along these lines appears to be stalled, it is not unreasonable to
admit the *possibility* that it might resume again.

Initially, clients may be configured to prefer SHA2-256 (which is
both mandatory to implement and has stood the test of time).  However,
later if there is any trouble on the SHA2 front, the client can be
updated to prefer SHA3 (when published by the server) to SHA2.

The proposed specification provides a transition mechanism with no
flag day, algorithms can be deprecated (relative to more preferred
algorithms) without being disabled.

If a server publishes:

	SHA2-256
	SHA2-512
	SHA3-256

And the client's preference order is (best to worst):

    SHA3-256,
    SHA2-512,
    SHA2-256,

then the client will only evaluate the TLSA records with SHA3-256 digests
and if none match, authentication fails.  Today the client can prefer:

	SHA2-256,
	SHA2-512

And, since both are currently believed well out of reach of even
state-funded adversaries, save itself the wasted cycles of computing
SHA2-512 when both are published.

The point of Wes's choice "B" is that clients don't have to impose
a flag on themselves and drop weakened algorithms entirely, given
that many servers may not be publishing anything stronger.  Instead
with "B", the client uses the strongest mutually available option.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 24 Mar 2014 05:57:18 +1100

In message <[email-masked]>, Viktor Dukhovni writ
> with "B", the client uses the strongest mutually available option.

If you don't trust a algorithm you should not be using it.  Period.
This fall back to this untrusted/broken algorithm is bad engingeering
and bad security practice.

If the site you want to email only has broken TLSA records, get
them on the phone to fix the problem.

Mark

---

From: Peter Palfrader <[email-masked]>
Date: Sun, 23 Mar 2014 20:10:37 +0100

> them on the phone to fix the problem.

Assume we may have reason to believe that SHA1 is within reach of well
funded adversaries, and assume it had a code-point in DANE.

Site A only publishes SHA1 entries.  Would rather do unauthenticated TLS
than trust SHA1?

Site B publishes both SHA2-512 and SHA1 entries.  Would you still want
to trust SHA1?

---

From: Mark Andrews <[email-masked]>
Date: Mon, 24 Mar 2014 06:25:57 +1100

In message <[email-masked]>, Peter Palfrader writes
> Site A only publishes SHA1 entries.  Would rather do unauthenticated TLS

You left out - report and refuse to send until fixed.
 
> Site B publishes both SHA2-512 and SHA1 entries.  Would you still want

Once you decide SHA1 is not acceptable you ignore the records with SHA1
hashes.

Publishing new hashes is trivial and will remain trivial.

Once a algorithm has reached the state where you don't trust it for a
purpose you don't use it for thar purpose.

Mark

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 23 Mar 2014 19:57:17 +0000

> You left out - report and refuse to send until fixed.

Broken is not a binary state.  Before previously reasonably sound
algorithms are fully broken, they are first tarnished, and our
confidence in their strength begins to fray.

Refuse to send is a strong reaction, when an algorithm is only
tarnished, with no known practical attacks, but known signs of
weakness.  Have you disabled RC4 in your browser yet?  If not, your
rather principled stand is "do as I say, not do I as do".

> Once you decide SHA1 is not acceptable you ignore the records with SHA1

A flag day, one can sensibly avoid, by incrementally phasing out
(hypothetically) SHA1 as server publish stronger records that include
(hypothetically) SHA1 to accommodate weaker clients in addition to stronger
digests.

> Publishing new hashes is trivial and will remain trivial.

Flag days remain a major deployment problem.

> purpose you don't use it for that purpose.

That's fine, except at Internet scale.  Windows 2003 servers still
top out at RC4-SHA1, and at least Exchange 2003 has a broken 3DES
implementation.   Many server operators only enable RC4 for
performance reasons.

When exactly should you or I disable RC4-SHA1 support?  Fortunately
in TLS cipher suites are negotiated.  I am trying to do the same
for DANE.

-- 
	Viktor.

---

From: Peter Palfrader <[email-masked]>
Date: Sun, 23 Mar 2014 21:00:08 +0100

> You left out - report and refuse to send until fixed.

No, that's not what the SMTP draft suggests.  When DANE is not there,
then servers just fall back to not authenticating a peer's cert, as they
do nowadays.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 23 Mar 2014 20:28:31 +0000

> then servers just fall back to not authenticating a peer's cert, as they

Indeed if one simply considers (again hypothetically) SHA1 to be
"unusable", then with no "usable" TLSA records, the connection
would fall back to unauthenticated TLS.

To do what Mark suggests, we'd have to treat SHA1 as usable, but
always fails.  That is new code to make SHA1 never match.  And
still I don't see anyone shooting themselves in the foot with
self-imposed flag days for a long time after an algorithm becomes
suspect.

I sees that, the unstated objection must be a belief that SHA2-256
will never fail, and thus we're wasting time designing solutions
to a non-problem.  While I don't believe in eternal unbounded
progress, and (barring a P=NP revolution) it is likely that at some
point we'll have algorithms that never need replacement, it is
perhaps premature to declare mission-complete with SHA2.

For if we are to take the threat of gradual degradation of our
confidence in SHA2 seriously, we need usable approaches for phasing
it out.  Flag days don't look like usable approaches to me.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 24 Mar 2014 07:51:38 +1100

In message <[email-masked]>, Viktor Dukhovni writ
> implementation.   Many server operators only enable RC4 for

And the reason for that is that is that Microsoft has no presure
on it to release service packs with newer algorithms as clients
fall back to the known too weak algorithms.  The clients are not
getting the security they think they are.

What Microsoft should do is release updated clients that do not
support RC4 and also release server packs which support newer
algorithms.

> in TLS cipher suites are negotiated.  I am trying to do the same

There is NOTHING preventing implementations from ranking hash algorithms.
There is NOTHING preventing implementations from having a accept/reject.

There is no reason to REQUIRE implementations to ranking hash algorithms.

Supporting out of date clients does a disservice to both yourself and
them.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 24 Mar 2014 10:01:25 +1100

In message <[email-masked]>, Viktor Dukhovni writ
> > then servers just fall back to not authenticating a peer's cert, as they

The SMTP draft says how to securely go from a email domain to a
CERT using DNSSEC and TLSA.  It does not say whether one should use
a non secure connection or not.  That is seperate policy.

> would fall back to unauthenticated TLS.

It might or it might not.  That is a seperate policy decision.
 
> always fails.  That is new code to make SHA1 never match.  

	One will have something like

		if (!supported(match))
			skip record;

>  And

I don't assume that it will never be broken.  I also don't think we
need to "if has_alg(a) then {} else {}".

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 23 Mar 2014 23:57:27 +0000

On Mon, Mar 24, 2014 at 10:01:25AM +1100, Mark Andrews wrote:

> a non secure connection or not.  That is separate policy.

Section 2.2:

    A Secure non-empty TLSA RRset where all the records are unusable:

	A connection to the MTA MUST be made via TLS, but authentication
	is not required. Failure to establish an encrypted TLS connection
	MUST result in falling back to the next SMTP server or delayed
	delivery.

No, it is primarily a draft for opportunistic SMTP TLS at Internet
scale, where per-destination policy does not scale.  The default
policy for the Internet as a whole, for reasons explained in the
introduction, cannot be PKIX authenticated TLS.  Therefore, when
the TLSA records are entirely unusable, and in keeping with Tony's
original work on the SRV draft, the client reverts to legacy
mandatory (practically always unauthenticated) TLS.

> It might or it might not.  That is a separate policy decision.

Policy can't revoke reality.  Without usable TLSA records SMTP TLS
cannot be authenticated at scale.  There can be pockets of
authenticated SMTP between some clusters of domains, but the scope
of the draft is the vast majority of MTA to MTA connections not
covered by explicit per-destination local policy.

> 	One will have something like

Which needs to be different from considering the record "unusable",
because the matching type is unknown to the client.  The record is
retained for purposes of determining whether any "usable" records
are found, but skipped without being used.  And still an unnecessary
flag day.

> > It seems that, the unstated objection must be a belief that SHA2-256

And yet you object to specifying a mechanism for non-disruptive
transition to better digests should one of the previously trusted
digests become tarnished.

Is the objection to the agility mechanism per-se, or to saying that
clients SHOULD employ it?

I seem to recall you saying that clients already *may* employ the
proposed mechanism.  If so server operators need to know that their
TLSA records SHOULD be structured to interoperate with policies
that ignore some subset of the published digests, so that part goes
into at least the operational considerations section, and likely
into the OPS draft.

Is it your view point then that the proposed mechanism should be
a BCP, and not a requirement?  Why?  What's the value of having a
free-for-all on how digests are phased out?  When servers don't
know that clients ignore weaker digests, they are more likely to
remove these from their TLSA records early, resulting in lower
security with clients that only support the weaker (but not
necessarily easily broken) digests.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 24 Mar 2014 10:54:35 -0400 (EDT)

On Sun, 23 Mar 2014, Viktor Dukhovni wrote:

> when the TLSA records are entirely unusable, and in keeping with Tony's

That's unfortunate. Perhaps it depends on the definition of "unusable",
but if all TLSA records for instance fail the RRSIG validation, I would
hope that postfix would abort delivery attempts and definately _not_
fallback to unauthenticated TLS.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 24 Mar 2014 15:33:46 +0000

On Mon, Mar 24, 2014 at 10:54:35AM -0400, Paul Wouters wrote:

> hope that Postfix would abort delivery attempts and definitely _not_
> fall back to unauthenticated TLS.

Unusable is quite different from "fails validation".  When "usable"
records are found, but none match (all fail validation), delivery
is aborted.

The "unusable" case is when at least one of the TLSA *parameters*
is unsupported, the digest value has an impossible length, or a full
value is malformed:

    example.com. IN TLSA ???(50) SPKI(1) SHA2-512(2) {hex for 64-byte blob}
    example.com. IN TLSA DANE-EE(3) ???(2) SHA2-512(2) {hex for 64-byte blob}
    example.com. IN TLSA DANE-EE(3) SPKI(1) ???(3) {hex for 64-byte blob}
    example.com. IN TLSA DANE-EE(3) SPKI(1) SHA2-512(2) {hex for 32-byte blob}
    example.com. IN TLSA DANE-EE(3) SPKI(1) Full(0) {not ASN.1 of SPKI}
    example.com. IN TLSA DANE-EE(3) Cert(0) Full(0) {not ASN.1 of X.509 cert}

If all records are "unusable", Postfix falls back to unauthenticated TLS.

The administrator may be in a position to configure Postfix to
"test-drive" "DANE TLS" in a mode where validation failures are
tolerated and logged (DANE audit rather than enforcement), but
that's quite different from ignoring validation failures.

The default (when DANE TLS is enabled) is "enforce".  Support for
"audit" mode is under development, and is not DANE TLS specific.
It supports audited fallback from all verified (authenticated) TLS 
policies to either enforced unauthenticated TLS, or even just plain
opportunistic TLS (with cleartext fallback).  In all cases failure
to arrive at the desired security state is logged.

-- 
	Viktor.

---

From: Peter Palfrader <[email-masked]>
Date: Mon, 24 Mar 2014 16:33:58 +0100

> fallback to unauthenticated TLS.

2.1. of draft-ietf-dane-smtp-with-dane-07:
}  When a DNS lookup failure (error or "bogus" or "indeterminate" as
}  defined above) prevents an SMTP client from determining which SMTP
}  server or servers it should connect to, message delivery MUST be
}  delayed.

Unusable thus would mean we don't know or like the digest type, or
usage, selector, or matching type.

The 07 dane smtp draft further says:
}  A Secure non-empty TLSA RRset where all the records are unusable:  A
}     connection to the MTA MUST be made via TLS, but authentication is
}     not required.  Failure to establish an encrypted TLS connection
}     MUST result in falling back to the next SMTP server or delayed
}     delivery.

Cheers,

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 24 Mar 2014 08:37:08 -0700

> fallback to unauthenticated TLS.

Yes, this is the case Paul (no need to worry).

>From 6698:

Within the SMTP draft, DNSSEC and, for that matter, any DNS error
indicates a full stop with that MX host.  It'll try other hosts, and if
they're broken too then delay.

The unusable indicates "I can't understand the TLSA record for some
reason", not "the hash didn't match" or "was not validated".
-- 
Wes Hardaker
Parsons

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 24 Mar 2014 09:02:48 -0700

> them on the phone to fix the problem.

I agree with you, that's the ideal right solution!  However, the world
is a bit bigger than you can safely war-dial with a problem.  This has
been proven time and time again by the slow role out of every protocol
on the planet.  EG, apparently not enough phone calls have been made to
the recursive resolvers of every ISP that fail to turn on DNSSEC
validation.  It's simply not scalable to fall back to a phone call, or
even automated email.  If we could, indeed, convince the world to
upgrade quickly just by contacting them, we wouldn't have a BCP38
problems, spam problems, IPv4 address space problems, and insecure
algorithms in use problems.  But we very very much do.  Otherwise,
shouldn't we also call every SMTP service provider for every zone and
tell them to turn on TLS?  We haven't done that either (nor will
anyone).

So, the alternative is to have a sliding roll-out that can support the
case where 50% of the world is in a new state and 50% is in the old
state.  Opportunistic turning-on of anything results in "when both
parties support it, it magically happens".  That includes both the
DANE/SMTP protocol itself, as well as the algorithm selection by
preferring a stronger one over a weaker one, but not stopping delivery
to the 50% of the world that hasn't switched yet.

The world has yet to succeed in a single flag day for any protocol.  Not
one.

-- 
Wes Hardaker
Parsons