Subject: [dane] #35: Behavior for a supported algorithm that is not considered "strong" by the client.

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

#35: Behavior for a supported algorithm that is not considered "strong" by the
client.

 This was entwined in discussions on Issue #22 and was not fully addressed,
 so I am opening it to be tracked.

 From http://www.ietf.org/mail-archive/web/dane/current/msg03366.html :
 "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 Schaad

 and from http://www.ietf.org/mail-archive/web/dane/current/msg03388.html :
 "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." --
 Jim Schaad

-- 
-------------------------------+--------------------------------------------
 Reporter:  warren@…           |       Owner:  draft-ietf-dane-protocol@…             
     Type:  enhancement        |      Status:  new                                    
 Priority:  minor              |   Milestone:                                         
Component:  protocol           |     Version:                                         
 Severity:  -                  |    Keywords:                                         
-------------------------------+--------------------------------------------

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

---

From: Warren Kumari <[email-masked]>
Date: Wed, 21 Sep 2011 18:24:42 -0400

Hello all,

This will hopefully be short and drama free.

Jim raised an interesting question during the Issue #22 discussions (that was not addressed in #22), and has proposed an answer:
" 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."

Does the WG feel that this is the correct behavior *for this case*? (+1 / -1 )

If so, does the WG feel that text to this effect should be added to the draft ? (+1 / -1) 

W

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 21 Sep 2011 15:46:34 -0700

> " 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…

The relevant text from the current draft says:
   If a certificate association contains a certificate usage, selector,
   or matching type that is not understood by the TLS client, that
   certificate association MUST be marked as unusable.  If the
   comparison data for a certificate is malformed, the certificate
   association MUST be marked as unusable.

   An application that requests TLS certificate associations using the
   method described in this document obtains zero or more usable
   certificate associations.  If the application receives zero usable
   certificate associations, it processes TLS in the normal fashion.

   On the first match between one of the certificate association(s) and
   the server's end entity certificate in TLS is found, the TLS client
   continues the TLS handshake, ignoring remaining certificate
   associations.  If no match between the usable certificate
   association(s) and the server's end entity certificate in TLS is
   found, the TLS client MUST abort the handshake with an
   "access_denied" error.

> Does the WG feel that this is the correct behavior *for this case*? (+1 / -1 )

-1. If you don't trust a hash function, you don't use it to create an untrusted comparison: you pretend that you don't know the hash function. Thus, the record is unusable. If there are no other records, then the text clearly says that the TLS handshake goes on in the normal fashion.

> If so, does the WG feel that text to this effect should be added to the draft ? (+1 / -1) 

+1, even though this is not "if so". It should be clarified.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 21 Sep 2011 20:03:09 -0400

Why would anyone implement SHA1 for a new protocol specification?

Remember that the DANE records are going to be signed using DNSSEC. Thus
there will be two digests involved.

If we are in a transition from algorithm A to algorithm B and there is a
point to it, then the DNSSEC records and the DANE records must be both
specified under both algorithms or there is no point to it.

So from a DANE standpoint there should probably be a requirement that there
is a digest value for all the algorithms used to sign the zone.
Alternatively, it that is considered administratively impractical, there
needs to be a DANE record that specifies the digests to expect in the DANE
records.

On Wed, Sep 21, 2011 at 6:46 PM, Paul Hoffman <[email-masked]> wrote:

> > Jim raised an interesting question during the Issue #22 discussions (that
> was not addressed in #22), and has proposed an answer:
> > " 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."
>
> -1. If you don't trust a hash function, you don't use it to create an
> untrusted comparison: you pretend that you don't know the hash function.
> Thus, the record is unusable. If there are no other records, then the text
> clearly says that the TLS handshake goes on in the normal fashion.
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

---

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

Paul,

I can completely understand the position that you are taking, and I wish I
had a really good reason for saying it is the "wrong" one.  Unfortunately I
don't.

Just to be clear and to make sure that you understand what I believe the
implications of you position are:

Suppose a host publishes a TLSA record with a matching requirement of
matching using the MUST-HASH1 algorithm (i.e. the algorithm is declared a
MUST implement by the DANE specification).

Suppose I have some super hacker who has come to me and given me a possible
proof that MUST-HASH1 algorithm is/has been broken but we have not yet gone
public (or any of a number of other reasons including the fact that I don't
like the US government and believe that they put a back door into the
algorithm).  Thus I have stated it will not be used by my clients (thus
making them unable to talk to half the world).

My client down loads the TLSA records for the website that I am connecting
to.  It finds the TLSA record for MUST-HASH1 and no other ones and my client
is fully DANE aware.  Your position is that I should toss out the fact that
there is a DANE record in existence and do normal TLS connection processing
even though the operator has attempted to give me a piece of good
information that have chosen not to believe.

In this case it is probable that normal processing would fail rendering the
whole thing moot as I would probably not accept the hash algorithm for doing
certificate path validation either.

As I said, I don't have a good reason for saying your position is incorrect.
If the group says that is the correct position I would not argue.  I just
want the position to be clearly stated.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Hoffman
> Sent: Wednesday, September 21, 2011 3:47 PM
> To: Warren Kumari
> Cc: DANE WG
> Subject: Re: [dane] #35: Behavior for a supported algorithm that is not
> considered "strong" by the client.
> 
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."
> 
untrusted
> comparison: you pretend that you don't know the hash function. Thus, the
> record is unusable. If there are no other records, then the text clearly
says
> that the TLS handshake goes on in the normal fashion.
> 
> > If so, does the WG feel that text to this effect should be added to the
draft
> ? (+1 / -1)

---

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

It's not clear from this what position you are taking.  Based on your
message I could setup the following straw man proposals, but I doubt any of
them would correspond to your actual position:

1.        Either you read a message I missed where somebody has suggested
that SHA1 be added to the DANE work, or you believe that the fact that I
suggested an algorithm might go bad in the future and we should deal with
this means that I believe that we should add SHA1 to the current work in
order to justify my position.

2.       None of the existing algorithms that have been suggested for
inclusion in the DANE work will ever go bad and therefore the suggestion
that it might go bad and we should address the issue is clear proof that I
have no idea of what happens in the real world.

3.       We would never be in a position of a catastrophic hash algorithm
failure with the current hash algorithms and there is always going to be
lots of time to do a transition and all operators are going to be efficient
about doing the transition so that new algorithms will always be rolled out
in sufficient time.

While I am starting to come to the opinion that the DANE effort is truly
going to need an operations document and I might be willing to be the
author, unless you believe that an operational approach is a sufficient
method of addressing the issue I raised, it would be more productive to say
that we should do BLAH and additionally add the following to the operations
recommendations.

Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Phillip Hallam-Baker
Sent: Wednesday, September 21, 2011 5:03 PM
To: Paul Hoffman
Cc: DANE WG
Subject: Re: [dane] #35: Behavior for a supported algorithm that is not
considered "strong" by the client.

 

 

 

> If so, does the WG feel that text to this effect should be added to the
draft ? (+1 / -1)

--Paul Hoffman

---

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

> had a really good reason for saying it is the "wrong" one.  Unfortunately I

Noted.

> information that have chosen not to believe.

Almost. The operator *did* give you a piece of good information; you subsequently chose not to believe it due to local policy.

> certificate path validation either.

Bingo. TLSA should not be in the business of saying "don't go forwards with TLS" in cases where you have made a local TLSA policy. If you don't trust a hash type, it is no different than you not understanding the hash type.

> want the position to be clearly stated.

Your example above is indeed clearer than the ones that started this thread, so thank you.

--Paul Hoffman

---

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

> author, unless you believe that an operational approach is a sufficient

This makes abundant amounts of sense. When the A record was standardized,
the RFC also refrained from telling folks how to subnet their networks.

I suggest the DANE RFC tries to keep it simple. DNSSEC and TLS are
complicated enough as they are.

Also, keep in mind that even if an RFC provides normative "guidance", as
long as it is not vital for interoperability, this guidance is likely to be
ignored or be applied confusingly.

	Bert

-- 
PowerDNS Website: http://www.powerdns.com/
PowerDNS Community Website: http://wiki.powerdns.com/

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 23 Sep 2011 12:51:09 -0400

> is a digest value for all the algorithms used to sign the zone.

I think it would be extremely unwise to start conflating keys that are
_in_ the zone, to be used for other purposes, and the mechanism of
securing the zone communication itself.  There is no reason that the
TLSA record's algorithms and the DNSSEC algorithms need be aligned,
and I don't understand why it might be considered a good idea.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 23 Sep 2011 17:03:18 -0400

The reason I see them as being linked is that either there is a problem with
the security of SHA256 or there is not.

If there is a problem discovered with SHA256 it may come in a desperately
bad must patch the Internet variety or be like SHA1 and be a significant
cause for concern but not of the hair on fire (yet) variety.

The desperately bad situation is actually the easy one to fix. We can push
out patches, force upgrades. It is do-able. Its the rising cause for concern
situation that is the problem.

If the client is still accepting SHA256 for the DNSSEC or the TLS security
scheme then we are almost certainly not in the 'hair on fire' situation. The
client is proposing to use a stronger algorithm because its the right thing
to do, not because SHA256 has been found unsafe.

That is why I think we can and should avoid complicating DANE by trying to
second guess every last possible corner case on the transition.