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

From: "dane issue tracker" <[email-masked]>
Date: Wed, 21 Sep 2011 04:27:19 -0000

#33: Publish enough information for the client to achieve the security of its
favorite digest

 There was a misunderstanding on ticket:22, so I'm restating the less
 controversial part of the proposal here.  The possible solutions are still
 those in ticket:22#comment:1.

-- 
------------------------------------+---------------------------------------
 Reporter:  matt@…                  |       Owner:  draft-ietf-dane-protocol@…             
     Type:  defect                  |      Status:  new                                    
 Priority:  major                   |   Milestone:                                         
Component:  protocol                |     Version:                                         
 Severity:  -                       |    Keywords:                                         
------------------------------------+---------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/33>
dane <http://tools.ietf.org/dane/>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 21 Sep 2011 11:01:42 -0400

Could you clarify what you mean by "the security of its favorite digest"?  

On Sep 21, 2011, at 12:27 AM, dane issue tracker wrote:

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 21 Sep 2011 08:28:07 -0700

> Could you clarify what you mean by "the security of its favorite digest"?  

+1 to the request for clarification. The current protocol says what digest function is being used by DANE.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Wed, 21 Sep 2011 11:39:05 -0400

> +1 to the request for clarification. The current protocol says what digest function is being used by DANE.

+1 again -- and the client gets the TLSA records and can choose "its favorite" already...

W

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 21 Sep 2011 19:35:06 -0700

> +1 again -- and the client gets the TLSA records and can choose "its favorite" already...

Suppose I as the client prefer SHA-512 to SHA-256 and wish to achieve
the security of SHA-512 whenever possible but still interoperate with
servers that do not fully support SHA-512.  I receive a TLSA RRset:

_443._tcp.example.com TLSA 1 0 SHA-512 xxxx
_443._tcp.example.com TLSA 1 0 SHA-256 yyyy

And the cert has SHA-256 yyyy but does not have SHA-512 xxxx.  Is this a
rollover in progress, or is someone trying to attack me via a SHA-256
second preimage?  If I try to choose my favorite digest, I fail against
servers performing legitimate rollovers.

Now do you get the point?

-- 
Matt

---

From: Paul Wouters <[email-masked]>
Date: Wed, 21 Sep 2011 23:09:02 -0400 (EDT)

On Wed, 21 Sep 2011, Matt McCutchen wrote:

> second preimage?

If you are doing a cert rollover, wouldn't you publish:

_443._tcp.example.com TLSA 1 0 SHA-512 cert1
_443._tcp.example.com TLSA 1 0 SHA-512 cert2
_443._tcp.example.com TLSA 1 0 SHA-256 cert1
_443._tcp.example.com TLSA 1 0 SHA-256 cert2

(perhaps the last entry omitted if you really deemed the danger worse the
losing the old clients)

Paul

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 21 Sep 2011 21:23:09 -0700

This demonstrates why I have said that an algorithm either is or is not good
enough.  While it could be doing a roll over, it could also be selecting the
certificate based on the criteria that you gave in the TLS handshake and
using the same hash algorithm for both the certificate and the TLSA
statement.

If your client wants to sort the TLSA records and process them in preferred
order, there is nothing to prevent that.  But you cannot assume that the
host operator has the same feeling for the algorithm that you have.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Matt McCutchen
> Sent: Wednesday, September 21, 2011 7:35 PM
> To: Warren Kumari
> Cc: Paul Hoffman; DANE WG
> Subject: Re: [dane] #33: Publish enough information for the client to
achieve
> the security of its favorite digest
> 
> > > +1 to the request for clarification. The current protocol says what
digest
> function is being used by DANE.
> >
> > +1 again -- and the client gets the TLSA records and can choose "its
favorite"
> already...
> 
> Suppose I as the client prefer SHA-512 to SHA-256 and wish to achieve the
> security of SHA-512 whenever possible but still interoperate with servers
that
> do not fully support SHA-512.  I receive a TLSA RRset:
> 
> _443._tcp.example.com TLSA 1 0 SHA-512 xxxx _443._tcp.example.com TLSA
> 1 0 SHA-256 yyyy
> 
second
> preimage?  If I try to choose my favorite digest, I fail against servers
> performing legitimate rollovers.
> 
>

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 21 Sep 2011 21:40:43 -0700

> (perhaps the last entry omitted if you really deemed the danger worse the

Maybe... I guess I shouldn't have said "rollover", but rather "the
server arbitrarily decides to publish the SHA-256 of one cert and the
SHA-512 of a different cert and then send me the first cert".  Stupid,
but legitimate; nothing in the spec licenses me to assume that servers
won't do that.  Adding a Cartesian product requirement is one of the
possible solutions.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 21 Sep 2011 22:00:24 -0700

On Wed, 2011-09-21 at 21:23 -0700, Jim Schaad wrote:
> enough.

If you have established minimum security requirements in advance and can
simply enforce them, good for you.  But most of the world does not
operate that way.  It's easier to just use the strongest algorithm
supported by both sides, and independently work to ensure that both
sides support sufficiently strong algorithms.  Since the web browser
market puts such a premium on availability against all the servers in
the world, it will inevitably end up setting a bare-minimum security
requirement unless we provide a downgrade-proof way to negotiate the
algorithm.

> While it could be doing a roll over, it could also be selecting the

Your point is lost on me.  Could you write out an example?

> order, there is nothing to prevent that.

I don't know what you are getting at by "order"; disjunction is
commutative.  Did you mean "process only the RRs of the algorithm I
consider strongest"?  If I do that I'll fail against servers that have
perverse but valid configurations, as in the example I gave.

> But you cannot assume that the

What do you mean?  The proposals under consideration are:

- Indicate which digests are of the same certificate, either via group
IDs or by concatenating all the info about one certificate in one RR.
- Require that the RRset be a Cartesian product of certs and algorithms.

Neither of these involves the server's algorithm preferences in any way.

-- 
Matt

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 21 Sep 2011 22:53:54 -0700

> From: Matt McCutchen [mailto:[email-masked]]
> Sent: Wednesday, September 21, 2011 10:00 PM
> To: Jim Schaad
> Cc: 'DANE WG'
> Subject: RE: [dane] #33: Publish enough information for the client to achieve
> > This demonstrates why I have said that an algorithm either is or is
> > not good enough.
> 
> simply enforce them, good for you.  But most of the world does not operate
> that way.  It's easier to just use the strongest algorithm supported by both
> sides, and independently work to ensure that both sides support sufficiently
> strong algorithms.  Since the web browser market puts such a premium on
> availability against all the servers in the world, it will inevitably end up setting a
> bare-minimum security requirement unless we provide a downgrade-proof
> way to negotiate the algorithm.
> 
> > certificate based on the criteria that you gave in the TLS handshake
> > and using the same hash algorithm for both the certificate and the
> > TLSA statement.
> 

Suppose the server has an RSA-SHA-256 certificate set and an ECC-SHA-512 certificate set.
There is one SHA-256 TLSA record for the first certificate and one SHA-512 TLSA record for the second certificate
Based on what you state as the algorithms you accept, one or the other of the certificates is returned as part of the TLS handshake.

You then check the received certificate against the two TLSA records and proceeded.

> 
> > If your client wants to sort the TLSA records and process them in
> > preferred order, there is nothing to prevent that.
> 
> I don't know what you are getting at by "order"; disjunction is commutative.
> Did you mean "process only the RRs of the algorithm I consider strongest"?  If I
> do that I'll fail against servers that have perverse but valid configurations, as in
> the example I gave.

You can process SHA-512 records first and then SHA-256 if that is what you want to do.  You must decide either to process and accept SHA-256 records or not.  If you accept them then you will accept them.  There is no problems.  If you choose not to accept them then you have the issue that I raised and is being addressed under issue #35.  Again there is no configuration problem.  

> - Indicate which digests are of the same certificate, either via group IDs or by
> concatenating all the info about one certificate in one RR.

You are asking for a new item to be setup that the RRset be a product of certs and algorithms.  That is a new requirement and will cause future problems.  What happens when SHA3 algorithms are introduced.  They will not be in the complete product set and thus cause problems.

There is no need to indicate which certificates are setup with which hash algorithms as all of the TLSA disjoint statements would be evaluated independently.

If your favorite algorithm is not present then you are just out of luck on wanting to use that algorithm in all cases.  You either accept the algorithm that is present or not.

Jim

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 21 Sep 2011 22:55:49 -0700

> You then check the received certificate against the two TLSA records and proceeded.

Sure.  So this is just another scenario with two authorized certificates
for which the TLSA digest offerings are different.

> You can process SHA-512 records first and then SHA-256 if that is what
> you want to do.

What significance can there possibly be to doing that?  Why do you
bother to mention it?  Disjunction is commutative?

> You must decide either to process and accept SHA-256 records or not.
> If you accept them then you will accept them.

Yes, that is exactly the dilemma in which the current schema places
clients.

> There is no problems.

The problem is that I can't achieve the security of SHA-512 with servers
that provide SHA-512 digests while remaining interoperable with servers
that don't.  Maybe this is not a problem to you.  Maybe MITM attacks are
not a problem to some people either.

> You are asking for a new item to be setup that the RRset be a product
> of certs and algorithms.  That is a new requirement

New with respect to what?

> and will cause future problems.  What happens when SHA3 algorithms are
> introduced.  They will not be in the complete product set and thus
> cause problems.

No, the requirement is that the RRset be a Cartesian product of a set of
certs with *a set* of algorithms.  This set of algorithms need not be
the entire registry.  You can have {cert1, cert2} x {SHA-256, SHA-512}
even after SHA-3 is assigned a hash type or, indeed, becomes mandatory
for clients to support.

But I actually prefer the other approach, specifically the variant of
concatenating all the info about a single certificate in a single RR.

> There is no need to indicate which certificates are setup with which
> hash algorithms as all of the TLSA disjoint

"disjunct"?

> statements would be evaluated independently.

That is the current semantics.  To solve the problem I stated above,
there is a need to indicate which certs are setup with which hash
algorithms, or alternatively guarantee that any hash algorithm that
appears at all appears for all certs.

> If your favorite algorithm is not present then you are just out of luck on wanting to use that algorithm in all cases.  You either accept the algorithm that is present or not.

Yes, of course.  The problem is that I cannot distinguish a legitimate
cert for which my favorite algorithm is not present from a downgrade
attack.

What is so hard about this?  Other protocols such as TLS renegotiation
indication get this right: if both peers support renegotiation
indication, they will use it (an MITM cannot trick them into not using
it), otherwise various fallback policies are applied.

-- 
Matt

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 22 Sep 2011 08:21:41 +0200

> concatenating all the info about a single certificate in a single RR.

This has the disadvantage that the RR can be quite large when providing multiple algorithms. It also makes the RR definition more complex - in fact I know of no other RR that has this type of variable internal data structure (except the CERT RR).

My preference would be

a) requirement for cartesian product (i.e., all associations for a given domain name must be published with the same set of matching 
b) add a association group field indicating what associations should be considered equal (i.e., the client may pick one association out of a given group)

	jakob

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 21 Sep 2011 23:58:34 -0700

On Thu, 2011-09-22 at 08:21 +0200, Jakob Schlyter wrote:
> This has the disadvantage that the RR can be quite large when
> providing multiple algorithms.

How is this a disadvantage?  DNSSEC clients have to retrieve the entire
RRset no matter how it is structured.

> It also makes the RR definition more complex - in fact I know of no
> other RR that has this type of variable internal data structure
> (except the CERT RR).
> 
> My preference would be
> 

But others will argue that (a) is limiting and less informative than it
could be and (b) is too ugly for the admins that don't use grouping.
There is no perfectly convenient solution.  I do hope that the people
who are +1 to solving #33 can form a coalition around the approach they
consider the least evil rather than split their vote across the
alternatives.

-- 
Matt

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 22 Sep 2011 09:00:48 +0200

> RRset no matter how it is structured.

Keeping the complexity and readability of the RR itself low is, at least for me as a DNS person, valuable.

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 22 Sep 2011 09:36:37 -0400

I think that what it comes down to is that zones MUST provide a digest value
for all certs under the digest used in the certificate and clients MUST
support DANE processing for all the digests that are supported in certs.

In other words, what is the point of insisting on SHA-512 in the DANE record
if the cert itself is signed using SHA-256?

Consider the following cases:

Case #1 rollover

Client accepts SHA256 and SHA512, so the rollover zone looks like this to
the client:

This gives the correct behavior for a cert that matches and a cert that does
not match.

Case #2 rollover - non SHA-512 capable client.

The zone above become.

_443._tcp.example.com TLSA 1 0 ?????
_443._tcp.example.com TLSA 1 0 ?????
_443._tcp.example.com TLSA 1 0 SHA-256 cert1
_443._tcp.example.com TLSA 1 0 SHA-256 cert2

This gives the correct behavior for a cert that matches and a cert that does
not match. Provided that the SHA-512 records are ignored completely.

Case #3 rollover - SHA-256 is untrusted

This is essentially the same as case #2.

The big difference is that insisting on a SHA-512 certificate has no point
unless the client can also process SHA-512 in its cert handling.

Now for the corner cases:

Case #4, no digest is known.

_443._tcp.example.com TLSA 1 0 ?????
_443._tcp.example.com TLSA 1 0 ?????

All the records are ignored and so the TLSA records become the null set and
that means allow anything.

Moral - zones must contain at least one widely supported digest (well duh!).

Case #5, zone has different certificates for the same keys using the same
digest as the cert in question:

_443._tcp.example.com TLSA 1 0 SHA-512 cert1-512
_443._tcp.example.com TLSA 1 0 SHA-512 cert2-512
_443._tcp.example.com TLSA 1 0 SHA-256 cert1-256
_443._tcp.example.com TLSA 1 0 SHA-256 cert2-256

This is the rollover case that makes sense to me since a client that can
process a digest in the cert should be able to process it in the DANE record
as well.

This is incidentally why you are still wrong about introducing a new
registry for DANE digest identifiers that has to be kept in sync.

This is only going to make sense once there is a deployed mechanism that
allows the TLS client to negotiate the cert algorithm.

Case #6 zone has digests for some keys but not others.

I think that the correct approach here is to tell the deployer why it won't
work and let them hang themselves.

The only real worry would be that nincompoops will deploy this type of
record and then try to insist on clients still respecting the SHA-256
record. I don't see that as a problem really.

-- 
Website: http://hallambaker.com/

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 22 Sep 2011 07:55:34 -0700

> rollover in progress, or is someone trying to attack me via a SHA-256

There is no sane way for a security protocol to fully deal with a preimage weakening for any supported hash algorithm. If you believe that this statement is incorrect, please point to the protocol that does.

> If I try to choose my favorite digest, I fail against

Others have already commented on this scenario, and I agree with them.

> Now do you get the point?

Yes, and I fully disagree with it. Your unstated assumption is that we can predict which hash functions will be considered stronger or weaker, and that is a false assumption.

Typical clients will assume that all allowed hash types are secure enough for their purposes. Atypical clients may have additional rules for picking between different hash types, and such picking-and-choosing is fully allowed by the protocol. Different atypical clients will have different additional rules, so a domain cannot do anything about them.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Sep 2011 17:28:06 +0200 (MEST)

Paul,

Paul Hoffman wrote:
> There is no sane way for a security protocol to fully deal with a preimage
> weakening for any supported hash algorithm.

"The way" is easy and straightforward: require the cartesian product
so that DANE clients distrusting one algorithm can entirely ignore
all records with that algorithm.

It doesn't seem like there is consenus that a requirement for an
cartesian product is a "sane way".  The problem is that it scales
so badly.

>
> If you believe that this
> statement is incorrect, please point to the protocol that does.

If a security protocol _protects_ the negotiation of common algorithm
between peers, then it just works.  Think of the TLS cipher suite
negotiation.

If DNSSEC ensures that an attacker can not hide only specific TLSA records
from the DANE client's view, then a client's selection by own preference
in combination with a cartesian product requirement would do the trick.

>
> Your unstated assumption is that we can predict which hash functions
> will be considered stronger or weaker, and that is a false assumption.

I do not believe that was asserted.
A protected negotiation or protected selection by preference scheme
will allow to securely choose a "weak" algorithm in exactly the same way
as securely choosing a "strong" algorithm, the is no bias in that scheme.

But as long as lots of the crypto stuff that is involved (TLS and DNSSEC)
has SHA1 all over the place and no realistic perspective to move those
protocols to somethings _stronger_ than SHA-256 anywhere soon,
support for allegedly stronger hash algorithms in DANE than SHA-256,
such as SHA-512 or SHA-3, amounts to bikeshedding.

-Martin

---

From: Paul Wouters <[email-masked]>
Date: Thu, 22 Sep 2011 14:51:47 -0400 (EDT)

> in combination with a cartesian product requirement would do the trick.

There is one RRSIG over the entire TLSA RRset. That RRSIG uses one
algorithm.  there will always be mismatches between hash algorithm used
in multiple TLS certs with different algorithms, algorithms used in the
TLSA record RData, and in the RRSIG.

It's up to DNS administrators and TLS administrators to pick which ones to
deploy and trust. It is up to the DNS and TLS clients to pick from that
published list what they trust. No new bits in the TLSA record is going to
change that.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 22 Sep 2011 16:27:10 -0400

> published list what they trust. No new bits in the TLSA record is going to

Not quite, there can be more than one RRSIG as that can be rolling as well.
In fact if there is a necessary roll for DANE there will almost certainly be
one for DNSSEC at the same time.

There are three separate places where a digest is relevant:

A) The certificate signature
B) The DANE record
C) The DNSSEC RRSIG(s)

The certificate signature and the DANE record are both specific to TLS and
it makes sense to consider those together.

I can think of cases where the DNSSEC digest algorithm might fall out of
sync with the choice of algorithm for TLS. The DNSSEC digest algorithm is
going to be a part of a chain and may well end up being ahead or behind. It
is also quite possible that the DNSSEC processing gets done somewhere else
entirely.

But I cannot see a case where a TLS library would be able to do SHA-X for
the TLS and not for DANE or vice versa.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 22 Sep 2011 17:24:33 -0400 (EDT)

> Not quite, there can be more than one RRSIG as that can be rolling as well.

True, but then you again publish two RRSIGs and its up to the client to
decide to not trust RSASHA1 or whatever. But if the situation is that
bad, you have a more serious problem, as everyone in your chain upto to
root might be rolling their algorithm, and you're subverted with rogue
TLSA records without your nameservers ever being contacted.

We put in algorithm agility to migrate before shit hits the fan. We should
not remain bikeshedding over theoretical doomsday scenario of global
nuclear hash failing.

> In fact if there is a necessary roll for DANE there will almost
> certainly be one for DNSSEC at the same time.

That totally depends on how the algorithm is broken. You might simple
be fine with RRSIG lifetimes of 1 day, which would protect your RSASHA1
RRSIGs from attack, but which would not prevent an X.509 signature to
be broken before it expires next year. Also, preimage attacks as MIT
did on the getting bogus certs signed would not work on DNSSEC, so I
really hope PKIX deployments would have moved to a stronger algorithm
long before there is any danger to its use in DNSSEC.

> The certificate signature and the DANE record are both specific to TLS and it makes sense to consider those together. 

A DNS admin can decide to use SHA256 in and on the TLSA record while the cert has
a SHA1 based signature. I don't see how they neccessarilly go together at all.

Paul

---

From: bert hubert <[email-masked]>
Date: Thu, 22 Sep 2011 23:35:17 +0200

> a SHA1 based signature. I don't see how they neccessarilly go together at all.

Also, much as a government that governs least governs best, standards should
not overreach. 

One can see arguments going both ways, in which case it is probably best to
leave it up to implementors.

Additionally, implementors rarely limit themselves to what a standard says
they MUST do where interoperability is not at stake, so it is futile anyhow.

	Bert

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 22 Sep 2011 18:00:41 -0400

> a SHA1 based signature. I don't see how they neccessarilly go together at

A Web server can have more than one cert and the client can direct the
choice of cert through the algorithm selection mechanism.

So the rule should be that the client is willing to use any of the digests
specified in the TLS algorithm negotiation for verifying the TLSA record or
the mandatory to implement digest.

So if the client tells the server that it will accept a cert with SHA512
then it has to be willing to accept a SHA512 digest in the TLSA record for
that cert.

In other words, we do not need to bother with any digest negotiation
mechanism at the DNS level because the TLS or IPSEC or whatever negotiation
will be sufficient.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 22 Sep 2011 16:17:18 -0700

On Sep 22, 2011, at 3:00 PM, Phillip Hallam-Baker wrote:

> In other words, we do not need to bother with any digest negotiation mechanism at the DNS level because the TLS or IPSEC or whatever negotiation will be sufficient.

+1. Good, succinct answer.

--Paul Hoffman

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 22 Sep 2011 21:50:41 -0700

On Thu, 2011-09-22 at 09:36 -0400, Phillip Hallam-Baker wrote:
> I think that what it comes down to is that zones MUST provide a digest
> value for all certs under the digest used in the certificate and
> clients MUST support DANE processing for all the digests that are
> supported in certs.
> 
> In other words, what is the point of insisting on SHA-512 in the DANE
> record if the cert itself is signed using SHA-256?

The DANE record may designate the cert directly, in which case the
signature on the cert is not used for anything.

[...]

> I think that the correct approach here is to tell the deployer why it
> won't work and let them hang themselves.

Except that it will work, because there is no Cartesian product
requirement in the spec.  That's the problem.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 22 Sep 2011 22:10:36 -0700

On Thu, 2011-09-22 at 07:55 -0700, Paul Hoffman wrote:
> There is no sane way for a security protocol to fully deal with a
> preimage weakening for any supported hash algorithm. If you believe
> that this statement is incorrect, please point to the protocol that
> does.

DNSSEC with respect to SHA-256 and SHA-1
( https://tools.ietf.org/html/rfc4509#section-3 second sentence).  It is
poorly explained, but DNSSEC is essentially adopting the Cartesian
product requirement.

It's true that a real system is likely to have some links in the chain
that are by their nature incapable of a downgrade-proof negotiation
(e.g., the TLS cipher suite handshake when an active attacker forces a
weak cipher suite and then forges the Finished messages, or verification
of X.509 certificate signatures), but that is no excuse not to do a
downgrade-proof negotiation every place we can.

> Others have already commented on this scenario, and I agree with them.

I am not sure precisely what you are agreeing with.  Link?

> will be considered stronger or weaker, and that is a false assumption.

I make no such assumption, see below.

> Typical clients will assume that all allowed hash types are secure
> enough for their purposes. Atypical clients may have additional rules
> for picking between different hash types, and such
> picking-and-choosing is fully allowed by the protocol.

But impossible to do without breaking interop with old servers.

> Different atypical clients will have different additional rules, so a
> domain cannot do anything about them.

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?

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 22 Sep 2011 22:16:55 -0700

On Thu, 2011-09-22 at 16:27 -0400, Phillip Hallam-Baker wrote:

> The certificate signature and the DANE record are both specific to TLS
> and it makes sense to consider those together. 
> 
> I can think of cases where the DNSSEC digest algorithm might fall out
> of sync with the choice of algorithm for TLS. The DNSSEC digest
> algorithm is going to be a part of a chain and may well end up being
> ahead or behind. It is also quite possible that the DNSSEC processing
> gets done somewhere else entirely.
> 
> But I cannot see a case where a TLS library would be able to do SHA-X
> for the TLS and not for DANE or vice versa.

I've got one: the client processes TLSA digests locally but delegates
all PKIX path validation (for non-TLSA servers as well as TLSA usage
types 0 and 2) via SCVP.

I wouldn't ever assume that the digest algorithms in different parts of
a system are in sync.  I recall complaints about TLS 1.2 imposing this
kind of requirement.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 22 Sep 2011 22:22:52 -0700

On Thu, 2011-09-22 at 18:00 -0400, Phillip Hallam-Baker wrote:
> So the rule should be that the client is willing to use any of the
> digests specified in the TLS algorithm negotiation for verifying the
> TLSA record or the mandatory to implement digest.
> 
> So if the client tells the server that it will accept a cert with
> SHA512 then it has to be willing to accept a SHA512 digest in the TLSA
> record for that cert.

This feels like a layering violation.  In addition, it is meaningless
with TLSA usage type 1, where the client doesn't use the certificate
signature for anything.

> mechanism at the DNS level because the TLS or IPSEC or whatever
> negotiation will be sufficient.

I must have missed something.  How does this solve the problem I stated
at https://www.ietf.org/mail-archive/web/dane/current/msg03440.html ?
Or do you object to that scenario?

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 22 Sep 2011 23:57:55 -0700

> published list what they trust. No new bits in the TLSA record is going to

Yes, but new bits could give clients the information to make a better
decision by distinguishing an odd but valid server configuration from an
attack, without the bits themselves saying anything about digest
strength.

-- 
Matt

---

From: Martin Rex <[email-masked]>
Date: Fri, 23 Sep 2011 20:52:27 +0200 (MEST)

Paul Hoffman wrote:
> 
> Phillip Hallam-Baker wrote:
> >
> > In other words, we do not need to bother with any digest
> > negotiation mechanism at the DNS level because the TLS or
> > IPSEC or whatever negotiation will be sufficient.
> 

Except that it does NOT apply to TLS, because TLS has no such
thing as a hash algorithm negotiation.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 23 Sep 2011 12:00:08 -0700

> thing as a hash algorithm negotiation.

The digest in the ciphersuite isn't a hash algorithm?

--Paul Hoffman

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 26 Sep 2011 00:00:55 -0700

> +1. Good, succinct answer.

Did you understand what you were agreeing with or did you just look for
any statement that sounded good and appeared to be in opposition to me?

Since the TLS cipher suite negotiation is authenticated by the server
certificate itself, it cannot provide any defense against replacement of
the certificate.  A MITM will just present the lookalike cert and claim
to support only the algorithm for which the cert is a second preimage,
forcing that algorithm to be negotiated.  I cannot speak for IPsec, but
we are currently targeting TLS anyway.

I know the TLS cipher suite negotiation as currently designed has
inherent weaknesses that make the DANE issue less relevant, but that's
no excuse not to get the DANE negotiation right, since I hope to use the
same approach to go back and fix TLS.

(I know you don't buy that there will ever come a time when a digest
algorithm is weak but not broken; I am pursuing this argument for the
sake of those in the WG who do and thus would be interested in a
proposal that helps with that scenario.)

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 26 Sep 2011 06:47:20 -0700

> any statement that sounded good and appeared to be in opposition to me?

Yes; no.

> algorithm is weak but not broken;

Please don't put words in my mouth, particularly ones that are false; it is exceedingly rude. I never said that. What I said was that if there is a weakening in the preimage resistance of one of the hashes we use, (a) it will likely happen slowly enough that everyone will stop using that algorithm anywhere before the attack is useful and (b) if it happens quickly, TLS authentication will be much, much less valuable than other attacks for which there will be wide publicity.

> I am pursuing this argument for the

Fully understand. I do not object to you pursuing the topic, and I hope I do not lie about what you say when you do. If there is rough consensus in the WG that the complexity and fragility of the solution is justified by the problem, you have at least proposed a solution.

--Paul Hoffman

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 26 Sep 2011 13:43:22 -0700

On Mon, 2011-09-26 at 06:47 -0700, Paul Hoffman wrote:
> Please don't put words in my mouth, particularly ones that are false;
> it is exceedingly rude. I never said that. What I said was that if
> there is a weakening in the preimage resistance of one of the hashes
> we use, (a) it will likely happen slowly enough that everyone will
> stop using that algorithm anywhere before the attack is useful and (b)
> if it happens quickly, TLS authentication will be much, much less
> valuable than other attacks for which there will be wide publicity.

I was mistaken about your position.  Thanks for the clarification.

We have no precedent to suggest what the aftermath of a second preimage
weakening might look like, but experience on all other issues suggests
that some percentage of servers won't upgrade until a cattle prod is put
to the sysadmins.  For instance, lots of servers including my
university's student information portal are still vulnerable to the TLS
renegotiation attack.  Hence my interest.

-- 
Matt

---

From: "dane issue tracker" <[email-masked]>
Date: Wed, 28 Sep 2011 15:59:05 -0000

Comment (by matt@…):

 So... in list discussion, I think I successfully answered all the
 objections except the subjective one of "complexity".  Are we ready for a
 preliminary consensus call?  I would ask that each person indicate, for
 each of the three proposed solutions, whether they prefer it ''to the
 status quo''.  If you want this problem solved, please do not -1 a
 solution simply because you prefer a different solution, or we are at risk
 of splitting the vote and not getting a solution at all.

-- 
----------------------+-----------------------------------------
 Reporter:  matt@…    |       Owner:  draft-ietf-dane-protocol@…
     Type:  defect    |      Status:  new
 Priority:  major     |   Milestone:
Component:  protocol  |     Version:
 Severity:  -         |  Resolution:
 Keywords:            |
----------------------+-----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/33#comment:1>
dane <http://tools.ietf.org/dane/>

---

From: Warren Kumari <[email-masked]>
Date: Wed, 28 Sep 2011 17:02:51 -0400

On Sep 28, 2011, at 11:59 AM, dane issue tracker wrote:

> preliminary consensus call?  

Well, it would appear that you have decided to start one....

> I would ask that each person indicate, for

And if folk do wish to show support for any of the 3 solutions I ask that they do it by Friday 13:00UTC.

Explicitly stating that you do not wish to support any of the 3 would also be helpful (even if you have already said do in the thread...

W

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 28 Sep 2011 16:22:29 -0700

> Explicitly stating that you do not wish to support any of the 3 would also be helpful (even if you have already said do in the thread...

I do not support any of the three, for the reasons given before.

--Paul Hoffman

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 28 Sep 2011 19:53:39 -0700

> And if folk do wish to show support for any of the 3 solutions I ask that they do it by Friday 13:00UTC.

Man, that is a short consensus call.  

For others' convenience in replying:

1. All digests of one cert in one RR
2. Cartesian product requirement
3. Group ID

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 28 Sep 2011 19:54:46 -0700

And this should surprise no one:

1. All digests of one cert in one RR: +1
2. Cartesian product requirement: +1
3. Group ID: +1

-- 
Matt

---

From: Martin Rex <[email-masked]>
Date: Thu, 29 Sep 2011 05:23:14 +0200 (MEST)

Matt McCutchen wrote:
> 
> Warren Kumari wrote:
> >
> > And if folk do wish to show support for any of the 3 solutions
> > I ask that they do it by Friday 13:00UTC.
> 
 
 -.5   1. All digests of one cert in one RR
 -.5   2. Cartesian product requirement
 -.5   3. Group ID

(yes, that's negatives)

Based on how *I* interpret NIST SP800-57 (Table3 pg.64 + Table4 pg.66)
the use of SHA-256 (and SHA-256 alone) is expected safe until at least 2030.

With that in mind, *I* am fine with no strong hash agility in place
in order to cut down on complexity.

Repeating my previous conclusion (at the end) of this message:
http://www.ietf.org/mail-archive/web/dane/current/msg03459.html

  protocols to something _stronger_ than SHA-256 anywhere soon,

-Martin

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 28 Sep 2011 20:44:39 -0700

> in order to cut down on complexity.

If that is the case, why support multiple hash algorithms at all?  Just
so Russia can use GOST?  We either will or will not need to move away
from SHA-256 during the lifetime of DANE.  I do not see the situation in
which the halfway job of algorithm agility we have now makes sense.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 29 Sep 2011 00:19:47 -0700

On Wed, 2011-09-28 at 23:02 -0700, Jim Schaad wrote:
> You may not think it makes sense, however some of us do.

Care to explain, or are we just reduced to a tug of votes?

For some complexity, you buy the ability to drop a weak algorithm,
gaining security against new servers and breaking against old ones,
while for slightly more complexity, you can gain the security against
the new servers without breaking against the old ones.  That's what it
comes down to.  I guess depending on how you evaluate complexity, the
first approach could come out as better.  I am disappointed though.

-- 
Matt

---

From: Warren Kumari <[email-masked]>
Date: Thu, 29 Sep 2011 09:32:09 -0400

> Man, that is a short consensus call.

If you had spoken to the chairs before kicking this off....

But I realize I'm being petty, so fine, lets extend it till Wednesday, that will be 7 days.

W

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 29 Sep 2011 15:56:21 +0200

> And if folk do wish to show support for any of the 3 solutions I ask that they do it by Friday 13:00UTC.

no support from me.

	jakob

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 29 Sep 2011 09:59:16 -0400

+1

(-3?)

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 29 Sep 2011 16:10:46 +0200

On 23. 9. 2011, at 7:10, Matt McCutchen wrote:
> (https://tools.ietf.org/html/rfc4509#section-3 second sentence).  It is

Just a side note.  I really don't want to sidetrack, but I have to comment.

DNSEXT is/has been arguing that this is a server requirement (a requirement
for the zone owner) and not a client (a DNSSEC Validator) requirement.

See recent Wouter's email to unbound-dev:
https://unbound.net/pipermail/unbound-users/2011-September/002039.html

And status of DNS client (DNS validator) implementations is that Bind doesn't
enforce the Cartesian product, Unbound doesn't.  (I don't know status for others.)

O.
--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 29 Sep 2011 16:16:13 +0200

> 1. All digests of one cert in one RR (-1)
> 2. Cartesian product requirement (-1)
> 3. Group ID (-1)

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 29 Sep 2011 16:18:40 +0200

Richard,

is that +1 for "no support" (it's quite confusion to vote +1 as a negative vote)?
E.g. it's -1 to all three proposed solutions?

O.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 29 Sep 2011 10:29:15 -0400

That's a +1 for "no support".  I included the -3 to try and clarify that it was three negative votes :)

--Richard

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 29 Sep 2011 09:27:43 -0700

> For others' convenience in replying:

I am +1 on the use case -- that is, I am in favor of providing for
(what I understand to be) Matt's goals in *some* fashion.  Of the

> 1. All digests of one cert in one RR

-1: unwieldy, complicates client-side processing.

> 2. Cartesian product requirement

-0: simple and reliable, but imposes potentially enormous wire overhead.

+1

zw

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 29 Sep 2011 22:20:11 -0700

> -1: unwieldy, complicates client-side processing.

I'm curious why you say this.  This approach provides exactly the same
data as the group ID approach, just in a different format that avoids
the redundancy in the cert usage and selector fields and avoids the need
for admins using only one digest to think about group IDs.  The
complexity of the client-side processing is essentially the same:
instead of iterating over the group IDs and then the RRs with each group
ID, you would iterate over the RRs and then the digests within each RR.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 29 Sep 2011 23:03:21 -0700

> not remain bikeshedding over theoretical doomsday scenario of global

If the servers did indeed migrate before the hash algorithm became
unacceptably weak, it would be fine.  But all the evidence we have from
similar scenarios suggests that some percentage of servers won't,
inevitably leaving the mainstream browsers between a rock and a hard
place.  So I'm so glad to see comment from someone involved more
directly in browser development than myself.

-- 
Matt

---

From: Zack Weinberg <[email-masked]>
Date: Fri, 30 Sep 2011 11:03:46 -0700

On Thu, Sep 29, 2011 at 10:20 PM, Matt McCutchen <[email-masked]> wrote:
> for admins using only one digest to think about group IDs.

Right now, the data portion of the RR is an opaque blob of known
length, which regardless of the opcodes, will be fed to memcmp().
(What you do to get the *other* argument to memcmp() varies with
selector and reference type, and what you do after the check varies
with usage type.) To put all digests of one cert in one RR, you would
need to define a parseable format for the data portion.  As far as I
know there is no other RR that needs this treatment, so we'd be making
up something new and adding code to all clients. If we keep it to one
digest per RR, we get the same functionality for free.

You make a good point about the redundant opcodes and extra work for
admins, but right now I don't think it outweighs the disadvantage of
more parsing code.

zw

---

From: Jim Schaad <[email-masked]>
Date: Wed, 28 Sep 2011 23:01:34 -0700

I do not support this modification.

Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Warren Kumari
Sent: Wednesday, September 28, 2011 2:03 PM
To: dane issue tracker
Cc: [email-masked]; [email-masked]
Subject: Re: [dane] #33: Publish enough information for the client to
achieve the security of its favorite digest

On Sep 28, 2011, at 11:59 AM, dane issue tracker wrote:

> #33: Publish enough information for the client to achieve the security 
> of its favorite digest
> 
> 
> Comment (by matt@.):
> 
> objections except the subjective one of "complexity".  Are we ready 
> for a preliminary consensus call?

> I would ask that each person indicate, for each of the three proposed 
> solutions, whether they prefer it ''to the status quo''.  If you want 
> this problem solved, please do not -1 a solution simply because you 
> prefer a different solution, or we are at risk of splitting the vote 
> and not getting a solution at all.

And if folk do wish to show support for any of the 3 solutions I ask that
they do it by Friday 13:00UTC.

Explicitly stating that you do not wish to support any of the 3 would also
be helpful (even if you have already said do in the thread...

W
> Reporter:  matt@.    |       Owner:  draft-ietf-dane-protocol@.
> Ticket URL: 
> <http://trac.tools.ietf.org/wg/dane/trac/ticket/33#comment:1>

---

From: Jim Schaad <[email-masked]>
Date: Wed, 28 Sep 2011 23:02:46 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Matt
McCutchen
Sent: Wednesday, September 28, 2011 8:45 PM
To: Martin Rex
Cc: [email-masked]
Subject: Re: [dane] #33: Publish enough information for the client to

On Thu, 2011-09-29 at 05:23 +0200, Martin Rex wrote:
> With that in mind, *I* am fine with no strong hash agility in place in 
> order to cut down on complexity.

If that is the case, why support multiple hash algorithms at all?  Just so
Russia can use GOST?  We either will or will not need to move away from
SHA-256 during the lifetime of DANE.  I do not see the situation in which
the halfway job of algorithm agility we have now makes sense.

--
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 30 Sep 2011 22:27:49 -0700

On Fri, 2011-09-30 at 11:03 -0700, Zack Weinberg wrote:
> need to define a parseable format for the data portion.

Yes, it could be something trivial like:

(cert usage, selector, (algorithm ID, 16-bit length, value)*)

> As far as I

What functionality are you envisioning reusing?  For RR pretty-printing
in DNS libraries, it's true that using group IDs would leave us with
less to change with respect to DS.  But DNS libraries do not generally
parse RRs for applications (aside from CNAME and DNAME, which operate
beneath the level of a DNS query), so either way, we would be
implementing the parsing in the DANE client code.

> admins, but right now I don't think it outweighs the disadvantage of

I'm not convinced that solution 1 does in fact require more code.  I'd
imagine the code to parse the RDATA into individual digest values would
be comparable in size to the code to collate RRs by group ID for
solution 3.  The rest is two levels of iteration, either way.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 30 Sep 2011 23:04:15 -0700

> Just a side note.  I really don't want to sidetrack, but I have to comment.

No, thank you for bringing this to my (and the WG's) attention.

> for the zone owner) and not a client (a DNSSEC Validator) requirement.

That's fine.  Ticket #33 does not propose any client requirements, it
just seeks to give clients that want to be smart the information they
need.

> enforce the Cartesian product, Unbound doesn't.  (I don't know status for others.)

Interesting, so virginia.gov botched the Cartesian product requirement
and Unbound failed secure, and Paul Hoffman et al. argued that algorithm
downgrade protection was more trouble than it is worth:

http://dnssec-deployment.org/pipermail/dnssec-deployment/2011-September/005455.html

I'm not sure how I feel about that.  But FWIW, I think that solution 1
for DANE (all digests of a single cert in a single RR) is very unlikely
to go wrong in the way we've seen with the Cartesian product.
Implementations are likely to generate that RR from a cert as a single
operation with flags for the digest algorithm(s) to include, and having
the data in a single RR (especially in the short term before
pretty-printing support is widespread) will strongly discourage DNS
admins to attempt the rearrangements of individual digests that could
break things.

-- 
Matt