Subject: [dane] Optimize the processing of multiple TLSA RRs

From: "yzw_iplab" <[email-masked]>
Date: Thu, 22 Sep 2011 13:19:00 +0800

Hi,all
According to the basic DANE protocol, multiple TLSA RRs may be maintained for one name and the related processing principle is discussed in the past several days. 
Although anyone of the multiple TLSA RRs can be used to successfully authenticate the server, the server may give them different preference in practice. 
For example, _443._tcp.example.com has the following two TLSA RRs:
_443._tcp.example.com TLSA 1 0  priority=3  SHA-512 xxxx
_443._tcp.example.com TLSA 1 0  priority=4  SHA-256 yyyy
Although the DNS system has no responsibility to rank them according to their different priorities (may be the weight metric is needed in addition) but always send all the available information to the client, the client can optimize the authentication process using the RR with the highest priority which is set by the TLS server according to its own realistic considerations.
I think it is a very important and useful extension of DANE protocol.
J
BR,
Zhiwei Yan

2011-09-22 

yzw_iplab 

发件人： dane-request 
发送时间： 2011-09-22  11:32:17 
收件人： dane 
抄送： 
主题： dane Digest, Vol 6, Issue 27 
 
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 
https://www.ietf.org/mailman/listinfo/dane
Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.
Send dane mailing list submissions to
[email-masked]
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/dane
or, via email, send a message with subject or body 'help' to
[email-masked]
You can reach the person managing the list at
[email-masked]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dane digest..."
Today's Topics:
   1. Re: #33: Publish enough information for the client to achieve
      the security of its favorite digest (Paul Wouters)
   2. Re: #35: Behavior for a supported algorithm that is not
      considered "strong" by the client. (Jim Schaad)
   3. Re: #35: Behavior for a supported algorithm that is not
      considered "strong" by the client. (Jim Schaad)
------------------------------------------------------------
From:  Paul Wouters <[email-masked]>
To:  Matt McCutchen <[email-masked]>
Subject:  Re: [dane] #33: Publish enough information for the client toachieve the security of its favorite digest
Date:  Wed21 Sep 2011 23:09:02 -0400 (EDT)
On Wed, 21 Sep 2011, Matt McCutchen wrote:
> 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 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]>
To:  "'Paul Hoffman'" <[email-masked]>
 "'Warren Kumari'" <[email-masked]>
Subject:  Re: [dane] #35: Behavior for a supported algorithm that isnot considered "strong" by the client.
Date:  Wed21 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.
> 
> On Sep 21, 2011, at 3:24 PM, Warren Kumari wrote:
> 
> > 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."
> 
> 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
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
------------------------------------------------------------
------------------------------------------------------------
From:  "Jim Schaad" <[email-masked]>
To:  "'Phillip Hallam-Baker'" <[email-masked]>
 "'Paul Hoffman'" <[email-masked]>
Subject:  Re: [dane] #35: Behavior for a supported algorithm that is notconsidered "strong" by the client.
Date:  Wed21 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.

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:
On Sep 21, 2011, at 3:24 PM, Warren Kumari wrote:
> 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."
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
_______________________________________________
dane mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dane

-- 
Website: http://hallambaker.com/
------------------------------------------------------------
_______________________________________________
dane mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dane

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 22 Sep 2011 09:42:38 +0200

Hi,

> I think it is a very important and useful extension of DANE protocol.

I quite don't understand what problem this extension does solve?

Could you please elaborate more on the use cases?

O.
[off-topic]
P.S.: Could you please not use the tiny tiny font (plain text is just fine).
I had a hard time reading your email without enlarging it several times.
Thanks
[/off-topic]
--
 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: "yzw_iplab" <[email-masked]>
Date: Thu, 22 Sep 2011 17:45:59 +0800

Dear all,
I mean the TLS server may have multiple certificates registered in the DNS system.
However, according to the efficiency and/or security consideration, the TLS server
may have different preference for them to be used. Then a priority metric can be 
included in the RR and then the client can use the most recommended TLSA RR.

Historically, the priority and weight in SRV do not be widely used in practice.
However, I think it will certainly be adopted in the future with the widely
development of Internet.
For our TLSA RR, we should foresee this use case and work on it in advance.
Maybe we can make this feature as an optional function at this early stage, but
it is a necessary try. 
What's your opinion?
BR,
Zhiwei

2011-09-22 

yzw_iplab

---

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

> included in the RR and then the client can use the most recommended TLSA RR.

This is at odds with the way that TLS works. TLS only allows the server to present one EE certificate. Thus, there is no "priority" among multiple certificates. The "Trusted CA Indication" extension can be used by the client to say which trust anchor they want to chain to, but that is a signal from the client to the server. 

Even if, in the future, TLS has better facility for the server to have multiple certs so that it might have a preference, I don't see why TLSA would need to be in the business of expressing that preference: it should *only* be part of TLS. That is, what would a client do if TLSA says the preference was "A B C" but the (future) TLS server said the preference was "C B A"?

--Paul Hoffman

---

From: Rob Stradling <[email-masked]>
Date: Thu, 22 Sep 2011 16:30:00 +0100

On Thursday 22 Sep 2011 16:16:11 Paul Hoffman wrote:
> > I mean the TLS server may have multiple certificates registered in the
> > DNS system. However, according to the efficiency and/or security
> > consideration, the TLS server may have different preference for them to
> > be used. Then a priority metric can be included in the RR and then the
> > client can use the most recommended TLSA RR.
> 
> This is at odds with the way that TLS works. TLS only allows the server to
> present one EE certificate.

It's true that a TLS Server may only "present one EE certificate" per 
handshake, but that doesn't mean it will always send the same "one EE 
certificate" in every handshake with every TLS Client.  Some examples...

Client specifies the SNI extension:

$ openssl s_client -connect sni.velox.ch:443 -servername alice.sni.velox.ch 2> 
/dev/null | head -n 4 | tail -n 2
Certificate chain
 0 s:/C=CH/ST=Zuerich/L=Zuerich/O=Kaspar Brand/CN=alice.sni.velox.ch

$ openssl s_client -connect sni.velox.ch:443 -servername bob.sni.velox.ch 2> 
/dev/null | head -n 4 | tail -n 2
Certificate chain
 0 s:/C=CH/ST=Zuerich/L=Zuerich/O=Kaspar Brand/CN=bob.sni.velox.ch

Client specifies certain cipher(s):

$ openssl s_client -connect tls.secg.org:40023 -cipher RSA 2> /dev/null | head 
-n 4 | tail -n 2
Certificate chain
 0 s:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/SN=Ontario/CN=tls.secg.org RSA 
1024 Server Certificate/C=CA

$ openssl s_client -connect tls.secg.org:40023 -cipher ECDSA 2> /dev/null | 
head -n 4 | tail -n 2
Certificate chain
 0 s:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/ST=Ontario/CN=tls.secg.org ECC 
secp256r1 Server Certificate/C=CA

> Thus, there is no "priority" among multiple
> certificates. The "Trusted CA Indication" extension can be used by the
> client to say which trust anchor they want to chain to, but that is a
> signal from the client to the server.
> 
> Even if, in the future, TLS has better facility for the server to have
> multiple certs so that it might have a preference, I don't see why TLSA
> would need to be in the business of expressing that preference: it should
> *only* be part of TLS. That is, what would a client do if TLSA says the
> preference was "A B C" but the (future) TLS server said the preference was
> "C B A"?
> 
> --Paul Hoffman
> 

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

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

Paul Hoffman wrote:
> This is at odds with the way that TLS works.

Existing PKIX/X.509 supports only one subject public key per certificate,
so a TLS which wants to supports a large variety of TLS cipher suites
(RSA, DSA, static-DH, ECDSA, GOST 34.10-2001), there is simply no
other way for the TLS server than using distinct server certificates.

And the former three PK algs/certs (RSA,DSA,static-DH) are as old as SSLv3.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Sep 2011 18:16:32 +0200 (MEST)

> Client specifies certain cipher(s):

Correct!

> $ openssl s_client -connect sni.velox.ch:443 -servername alice.sni.velox.ch
> 
> $ openssl s_client -connect sni.velox.ch:443 -servername bob.sni.velox.ch 

Inappropriate example for the original discussion (DNS TLSA lookup)

A DANE client ought to lookup the DNS name of the host to which
it _connects_, and likewise, a DANE-aware TLS client ought to look up
the TLSA record for the exact same hostname that it uses for connect(),
and when that client sends SNI, it should be sending exactly that name
that it used for connect() and TLSA lookup.

Therefore both of your openssl s_client command lines are _not_ using SNI
in the fashion that it is supposed to be used by TLS client, because both
use a different name for connect() than what they send in SNI.

If a TLS client is doing what you do above, then I believe that
it is impossible to perform any sensible DANE TLSA lookup and
matching on the resulting server certificate!

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Sep 2011 18:43:36 +0200 (MEST)

I'm sorry for doing to many things at the same time...
Fixing up my last my last message below.

> Inappropriate example for the original discussion (DNS TLSA lookup)
 
A DANE-aware TLS client ought to look up the TLSA record for the exact
same hostname that it uses for connect(), and when that client sends SNI,
it should be sending exactly that name that it used for connect() and
TLSA lookup.

-Martin

---

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

> According to the basic DANE protocol, multiple TLSA RRs may be maintained
> for one name and the related processing principle is discussed in the past
> several days.  Although anyone of the multiple TLSA RRs can be used to

Compared to the cost of DH or RSA negotiation ("a millisecond", minus round
trips even), certificate validation ("few microseconds") is nearly free. 
The complexity added by this proposal would not be however.

So I suggest leaving out this optimization.

	Bert

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