Subject: [dane] Reopening issue #22 for discussion....

From: Warren Kumari <[email-masked]>
Date: Wed, 14 Sep 2011 17:52:36 -0400

Hi all,

A while back I (prematurely) closed issue #22 ( http://trac.tools.ietf.org/wg/dane/trac/ticket/22 -- Provide the security of the strongest digest supported by both sides ).

I had thought that we had had discussions on-list to the effect of:
While it may be fun, we cannot / should not specify what the strongest digest is, and so we cannot really dictate how sides choose the "strongest", and so client implementations will sort / choose the digest that they believe is strongest.
(I also thought I remembered discussions regarding if we needed to specify that client implementations should do this, but it was decided that that should just be an implementation detail).

I have not been able to find these discussions, and so it may just just been:
A: in person discussions or (more worrying)
B: a weird dream...

Anyway, let's discuss this and get it closed...

W

---

From: [email-masked]
Date: Thu, 15 Sep 2011 13:19:37 +0000

> Anyway, let's discuss this and get it closed...

	The only way to ensure client/server agreement is to only provide a single datum
	for consideration.  When/If there is a choice, there is no perfect assurance that
	there will be agreement between server and client as to the respective merits of 
	the data under consideration.    Server may assert datum(A) is perfered/strongest/blond,
	while client polcy will dictate that ginger is to always be prefered to blonds, other
	attributes be hanged.

	The server can't strong arm clients. Period.  (think deployed base and then making a
	change...  going to upgrade everything in the field?  Good Luck w/ that)

/bill

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 15 Sep 2011 08:34:27 -0700

I would prefer that we do not adopt the proposed design change.

> 	change...  going to upgrade everything in the field?  Good Luck w/ that)

+1. Further, I disagree with the part of the problem statement that says "clients that support SHA-512 will still accept any certificate that matches the SHA-256 digest". Clients that care about different strengths can be configured not to do this.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Thu, 15 Sep 2011 11:36:41 -0400

On Sep 15, 2011, at 9:19 AM, [email-masked] wrote:

> 	The server can't strong arm clients.

Exactly -- the best the server can do is announce all of the TLSA records (potentially with different algorithms) and the client can select what it thinks is best....

I think we are in violent agreement, but canna tell!

W

> Period.  (think deployed base and then making a

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 15 Sep 2011 11:27:02 -0700

We do however need to say what a client is to do in the event that a record
exists, but the client does not believe that it is a sufficiently strong
matching.  I.e. if my client says that SHA-1 will not do for anything, what
happens if only a SHA-1 record exists.  Is this considered to be an unusable
statement or a failed statement.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Hoffman
> Sent: Thursday, September 15, 2011 8:34 AM
> To: DANE WG
> Subject: Re: [dane] Reopening issue #22 for discussion....
> 
> > 	The server can't strong arm clients. Period.  (think deployed base
and
> then making a
> +1. Further, I disagree with the part of the problem statement that says
> "clients that support SHA-512 will still accept any certificate that
matches the
> SHA-256 digest". Clients that care about different strengths can be
> configured not to do this.
> 
> --Paul Hoffman
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 15 Sep 2011 11:02:43 -0700

> statement or a failed statement.

What is a "failed statement"? We don't have that in the current document.

Saying "you MAY consider this certificate unusable" doesn't seem at all useful to me, but if others want it, we can add it.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Sep 2011 22:09:42 +0200 (MEST)

Warren Kumari wrote:
> Exactly -- the best the server can do is announce all of the TLSA
> records (potentially with different algorithms) and the client can
> select what it thinks is best....

Since there is no negotiation involved when looking up TLSA records,
we may be better off being clear about the algorithm.

Do we want to require DNS admins to maintain SHA-512 (or any other
hash other than SHA-256) hashes for _all_ permissible server certs
for a given server host name whenever they add a certificate association
for one certificate with SHA-512, so that a client can first scan
the entire list of TLSA records for the algorithm it considers the
strongest, and then have the client ignore _all_ other TLSA records
when doing the matching?

i.e. when a server should have three valid certs,
and three TLSA records with SHA256 hashes of these certs respectively,
plus only a single TLSA record with SHA512 for just one of those certs,
then is this supposed to be a configuration error leading to interop
problems for clients that prefer SHA-512 over SHA-256?

Protocol-wise, requiring a full set of associations for each hash
algorithm, that the domain admin wants to offer/configure, seems like
the only approach that could provide better security during the
migration period.

But frankly, as long as the TLS of the current connection still
involves SHA-256 (or even SHA-1) and as long as the chain of DNSSEC
signatures protecting those TLSA records still use SHA-256
(or even SHA-1), the security benefit of a TLSA with SHA-512 over
TLSA with SHA-256 looks quite insignificant to me.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 15 Sep 2011 13:23:25 -0700

> we may be better off being clear about the algorithm.

Current wording in the spec:
   DNS systems conforming to this specification MUST be able to create
   TLSA records using matching type 0 (no hash used) and matching type 1
   (SHA-256), and SHOULD be able to create TLSA records using matching
   type 2 (SHA-512).

> strongest, and then have the client ignore _all_ other TLSA records

Why require that at all? Why tell the DNS system what specific hash to use?

> problems for clients that prefer SHA-512 over SHA-256?

No.

> the only approach that could provide better security during the

I propose that we don't go the route of complicated algorithm transition schemes. It has hurt DNSSEC badly already, with no clear benefit.

> TLSA with SHA-256 looks quite insignificant to me.

+1

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Sep 2011 23:02:27 +0200 (MEST)

Paul Hoffman wrote:
> Martin Rex wrote:

We don't tell the DNS system anything. (Don't we have to retrieve _all_
TLSA records in order to check the DNSSEC signature?)

We tell the DANE client the algorithm for matching the TLSA records and
the DNS admin how to correctly enter/configure the data.

> > problems for clients that prefer SHA-512 over SHA-256?

The problem I see with _not_ doing this is that we're actually cheating
about hash agility -- because it will not work.

When not doing this, different hashes may still be used to render
the address bar in different shades of green depending on which
hash was in the TLSA record that matched.

But the hash algorithm agility and security of a protocol is not about
the beautiful colors it can create when it works, but only about how
it fails if it is attacked.

If one worries about SHA-256 instead of SHA-512 hashes for the server
certificate, then this is about possible hash collisions.  And as long
as there is a valid TLSA record with a SHA-256 hash value, the weakest
link are collisions to that SHA-256 hash value.  If there is no means
to stop the client from matching TLSAs with SHA-256, then there is
no security value in providing additional TLSAs with SHA-512.

-Martin

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 15 Sep 2011 14:25:29 -0700

> no security value in providing additional TLSAs with SHA-512.

So I get the impression you want language along these lines:

# If the RRset contains multiple TLSA records with the same
# association type but different reference types, then after
# discarding all records with unsupported reference types, the
# client SHOULD rank the records by hash strength and discard all
# but the strongest.  For example, if the RRset contains two TLSA
# records with the same association type, but one carries a SHA-1
# hash and one carries a SHA-256 hash, a client which supports
# SHA-256 SHOULD ignore the record with the SHA-1 hash.

(Please clarify if this is not what you want.)

The problem I see with this is, there's no way to tell whether the two
records are meant to be the SHA-1 and SHA-256 of the *same* certificate.
If the two records are SHA-1(old-cert), SHA-256(new-cert) and the
admin's going to remove the former after the change from old-cert to
new-cert has a chance to settle, this would be the wrong behavior.
The only way around this problem that I can think of at the moment
is something like Matt's group-number proposal, only with different
semantics: the group number would indicate which subsets of the
RRset should be subject to ranking by hash strength.

zw

---

From: [email-masked]
Date: Thu, 15 Sep 2011 21:46:14 +0000

> no security value in providing additional TLSAs with SHA-512.

	the "one" you refer to above - is that the server or the client?

	As a server, publishing -256 and -512 hashes would imply, to me,
	that there exist clients for whom they -ONLY- support -256 or -512.
	the fallback for clients which support both is a crap shoot, whichever
	hash they get to first.

/bill

---

From: Martin Rex <[email-masked]>
Date: Fri, 16 Sep 2011 00:26:05 +0200 (MEST)

> 	the "one" you refer to above - is that the server or the client?

In the current scope, the TLS client that implements DANE.

> 	the fallback for clients which support both is a crap shoot, whichever

SHA-256 is mandatory to implement, SHA-512 is optional.

The primary reason for hash agility is being able to switch to a
different algorithm at some point in the future, when SHA-256 is no
longer deemed adequate.

The issues you're facing:
 - for interop with the installed base DANE clients you'll have to continue
   providing TLSA records with SHA-256 hashes for many years (10+) to come

 - for new DANE clients to obtain security benefit from TLSA records with
   a stronger hash, new DANE clients will have to ignore all records with
   a weaker hash as soon as they find a records with a stronger hash (that
   they implement) for a given server host name.

 - to provide smooth migration and interop for heterogeneous installed
   base of old and new DANE clients, the DNS admin must provide
   TLSA records with certificate hashes consistently for all desired
   hash algorithms for a given server host name.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 16 Sep 2011 00:46:28 +0200 (MEST)

> statement or a failed statement.

Like the situation that the DNS admin has configured only
TLSA records with SHA-512 hashes of certificates and a DANE client
that does not support SHA-512 hashes connects to the server.

Yes, the document should specify the desired client behaviour.

Does the client "groom" the list of TLSA records first, removing
all unsupported types (such as those with SHA-512).  Ending up
with an empty list of associations, should it continue with
normal TLS server certificate validation and server endpoint
identification, or should it abort because it could not perform
a DANE validation due to the lack of TLA records with supported types?

I see two possible behaviours:
 (1) continue normal TLS server certificate validation and server
     endpoint identification (as if there were no TLSA records)

 (2) fail the DANE server cert validation, which MUST (by default)
     abort the handshake/connection

and I'm having difficulties deciding which I would prefer personally.
I believe I'm leaning for (1), but wondering whether there should be
a means in DANE for the domain admin to ask for (2).
(No, I don't think that (2) should be unconditionally implied.)

-Martin

---

From: Paul Wouters <[email-masked]>
Date: Thu, 15 Sep 2011 19:10:15 -0400 (EDT)

> (No, I don't think that (2) should be unconditionally implied.)

Assuming that the TLSA RRset has been validated, and no specific Resource
Records were removed, if the RRset contains no hashes the client understands,
I think it should proceed as if the TLSA records are not present. However,
that does seem to be a matter of local client policy. If a client knows there
should be a usable TLSA record, and there is none, it might want to abort.

I don't think the DNS admin should be allowed to make that call. Just like
the server gives the TLS client a PKIX chain, and leaves it up to the client
to decide to proceed or not.

Paul

---

From: [email-masked]
Date: Thu, 15 Sep 2011 23:21:12 +0000

>    providing TLSA records with SHA-256 hashes for many years (10+) to come

	-if- backward interoperablity is desired, yes (30+) years if BIND is
	any predictor.

>    they implement) for a given server host name.

	thats not going to fly operationally.  the server s going to have to
	cease publication of all weaker hashes - forcing clients to upgrade.

	thats the proven operational method.  if the weaker hash exists it will
	get used.  anything else is simply gyrations and conplex code paths in
	the client to try and figure out what the server was trying to say by 
	speaking spanglish, finnish, and mayan...   is there a credible reason to
	try and burden the client code with this goofy logic?  seems like an ideal
	breeding ground for security exploits.   

>    hash algorithms for a given server host name.

	can I have some of what you are smoking?  please?

---

From: Martin Rex <[email-masked]>
Date: Fri, 16 Sep 2011 01:28:57 +0200 (MEST)

> to decide to proceed or not.

I'm sorry for causing a misunderstanding.

I was wondering whether the DNS admin should have a means to determine
the result of the DANE validation (only) by a DANE client, in presence
of TLSA records for a given server host name, but no TLSA records
that this DANE client supports.

I do not want to entitle DANE for an unconditional hard fail that the
user could not override, similar to that I do not entitle PKIX to
*require* OCSP plus hard fail for my TLS client.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 15 Sep 2011 19:33:34 -0500

I dont see it as an issue.

Chrome and Firefox both autopatch. They are the only browsers by companies attending DANE sessions.

By the time anyone with a static browser deploys Sha3 will have been announced.

Legacy is a real hazzard in the browser world. But not for any mainstream browser deployed in the past four years. The IE4 or Bind thing does not apply.

I cant imagine any group that deployed DANE being asleep on sha3 deployment.

Sent from my iPad

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 15 Sep 2011 20:47:36 -0700

> From: Martin Rex [mailto:[email-masked]]
> Sent: Thursday, September 15, 2011 3:46 PM
> To: Jim Schaad
> Cc: [email-masked]; [email-masked]
> > We do however need to say what a client is to do in the event that a
> > record exists, but the client does not believe that it is a
> > sufficiently strong matching.  I.e. if my client says that SHA-1 will
> > not do for anything, what happens if only a SHA-1 record exists.  Is
> > this considered to be an unusable statement or a failed statement.
> 
> Like the situation that the DNS admin has configured only TLSA records
with
> SHA-512 hashes of certificates and a DANE client that does not support
SHA-
> 512 hashes connects to the server.
> 
> Does the client "groom" the list of TLSA records first, removing all
> unsupported types (such as those with SHA-512).  Ending up with an empty
> list of associations, should it continue with normal TLS server
certificate
> validation and server endpoint identification, or should it abort because
it
> could not perform a DANE validation due to the lack of TLA records with
> supported types?

My understanding is that yes, the client does "groom" the list of TLSA
records first, removing all unsupported types (such as the apply strange
logic or PGP cert type) from the list first.  This is documented behavior as
removing things which are unusable.  If the list at that point is empty,
then normal processing is done.

My issue is a different one, we "support" the type, but say that it is for
some reason not secure.  (i.e. the 8-bit add all the bytes together hash
function.)  In this case I don't know what the behavior should be.  I think
it should be, this is a usable (I know what it means) but a record which
always fails evaluation (i.e. the hash value never matches) and thus if no
other usable records exist then the TLS handshake would be aborted.

The behavior of grooming the list is required so that new records can be
added in the future without causing sudden failures to occur.

Jim

> I believe I'm leaning for (1), but wondering whether there should be a
means
> in DANE for the domain admin to ask for (2).

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 19 Sep 2011 09:16:12 +0200

>     abort the handshake/connection

I think we already established that we want (1) as general behaviour.
From the client point of view, there's no difference between receiving
unknown hash algorithm and invalid hash.

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: Mon, 19 Sep 2011 09:21:08 +0200

Hi,

I think this is a very reasonable argument and I agree with Phil here.

Anyway it seems that we are sidetracking (again), so can we _all_ please
stick with #22 and respond if you agree with Warren's mail:

> While it may be fun, we cannot / should not specify what the strongest digest is, and so we cannot really dictate how sides choose the "strongest", and so client implementations will sort / choose…

rephrased by Bill as:

> 	change...  going to upgrade everything in the field?  Good Luck w/ that)

So the group decision would be that we cannot and we should not enforce "strongest" algorithm in the DANE protocol.

Please really try to respond with +1 / -1, so we can get rid of the issue fast.

O.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 19 Sep 2011 11:52:08 -0700

+1

An algorithm either is or is not strong enough - thus no ranking needed.

> Ondrej Surý
> Sent: Monday, September 19, 2011 12:21 AM
> To: Phillip Hallam-Baker
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Anyway it seems that we are sidetracking (again), so can we _all_ please stick
> with #22 and respond if you agree with Warren's mail:
> 
> > While it may be fun, we cannot / should not specify what the strongest
> digest is, and so we cannot really dictate how sides choose the "strongest",
> and so client implementations will sort / choose the digest that they believe
> is strongest.
> 
> 
> rephrased by Bill as:
> 
> So the group decision would be that we cannot and we should not enforce
> "strongest" algorithm in the DANE protocol.
> 
> > Legacy is a real hazzard in the browser world. But not for any mainstream
> browser deployed in the past four years. The IE4 or Bind thing does not
> apply.
> >
> >>> - for interop with the installed base DANE clients you'll have to
> >>> continue  providing TLSA records with SHA-256 hashes for many years
> >>> (10+) to come
> >>
> >>> - for new DANE clients to obtain security benefit from TLSA records
> >>> with  a stronger hash, new DANE clients will have to ignore all
> >>> records with  a weaker hash as soon as they find a records with a
> >>> stronger hash (that  they implement) for a given server host name.
> >>
> >>> - to provide smooth migration and interop for heterogeneous
> >>> installed  base of old and new DANE clients, the DNS admin must
> >>> provide  TLSA records with certificate hashes consistently for all
> >>> desired  hash algorithms for a given server host name.
> >>
>  Ondrej Sur
>  vedouc  v zkumu/Head of R&D department
>  CZ.NIC, z.s.p.o.    --    Laboratore CZ.NIC

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 19 Sep 2011 22:20:47 +0200

+1

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 19 Sep 2011 16:22:07 -0400

+1

And SHA-3 is either announced or not announced in time. If it is announced I
would argue for adding it to the spec as a MUST[*] but I would not argue for
delaying the spec to wait on the announcement.

[*] I do not believe in SHOULD for crypto algorithms. My view is that the
IETF should only give algids for required algorithms and that vanity crypto
should be supported only through an exception mechanism.

2011/9/19 Jim Schaad <[email-masked]>

> stick

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

---

From: Warren Kumari <[email-masked]>
Date: Tue, 20 Sep 2011 19:35:18 -0400

> Please really try to respond with +1 / -1, so we can get rid of the issue fast.

Ok, and we seem to be achieving consensus on this -- "DANE cannot (and should not) try enforce a "strongest" algorithm" -- as it's the wee hours of the morning in Prague my co-chair is (presumably) asleep and so I'm calling this without his input. If he disagrees on the consensus he'll poke me with a pointy clue stick and we'll reopen the issue (again).

W

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 20 Sep 2011 21:35:50 -0700

[Finally coming back to DANE discussion...]

On Mon, 2011-09-19 at 09:21 +0200, Ondřej Surý wrote:
> > While it may be fun, we cannot / should not specify what the
> strongest digest is, and so we cannot really dictate how sides choose
> the "strongest", and so client implementations will sort / choose the
> digest that they believe is strongest.
> 
> rephrased by Bill as:
> 

There was a severe misunderstanding here.  I should have better
separated the two parts of the proposal:

a. Publish enough information that the client /can/ achieve the security
of the "strongest" digest offered by the server.

b. State that clients SHOULD or MUST do so for a given definition of
"strongest".

The proposed decision is to not do "b".  I do not feel strongly about
that.  But to not do "a" would undercut the notion that we have achieved
algorithm agility.  To me, algorithm agility means that peers that wish
to use a new algorithm can immediately receive the security benefits
while remaining fully interoperable with peers that do not support it.
If we do not achieve this, then the only reason to support multiple
algorithms at all would be in anticipation of a slow and/or breaking
transition.

I have moved "a" to https://trac.tools.ietf.org/wg/dane/trac/ticket/33 .

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 20 Sep 2011 22:06:14 -0700

> I would prefer that we do not adopt the proposed design change.

Do you have an articulable objection to the "provide enough information"
part of the proposal, now moved to ticket #33, or do you just believe it
is not worth the effort?

> Further, I disagree with the part of the problem statement that says
> matches the SHA-256 digest". Clients that care about different
> strengths can be configured not to do this.

Sure, but the mass-market browsers will never do that.  Whereas, with
the proposal, they would be able to achieve what they believe is the
strongest possible security with every server.  I don't care how much
you disdain browsers; we are missing an opportunity to do a greater
service to this large segment of the public.

-- 
Matt

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 21 Sep 2011 16:44:08 +0200

Matt,

my understanding of the consensus is that the DANE WG cannot decide
strength of the algorithms.  As said by somebody before me: "algorithm
is either strong-enough or not strong-enough".

> of the "strongest" digest offered by the server.

As for #33 (or #22 comment#1) I didn't notice that before, but there's
nothing in the DNSSEC protocol about choosing the strongest algorithm
(there's only the mess about Carthesian product in the draft).

I think we addressed #22 and #33 in one go and both should be closed.
Could I receive few +1/-1 from other WG members, so we can either
decide this needs more discussion (-1s) or it's already solved as part
of #22 (+1s).

O.