Subject: Re: [dane] #31: Multiple TLSA records in a response

From: Jakob Schlyter <[email-masked]>
Date: Thu, 1 Sep 2011 09:43:20 +0200

On 1 sep 2011, at 08:13, yzw_iplab wrote:

> In both cases, the authentication failure period may last for 1/2*RTT(DNS server-TLS server).

This is not correct. In case of multiple certificate associations (TLSA RRs), any of them is enough for a match and there will will be no authentication failure period during a rollover (as long as multiple TLSA RR are published).

	jakob

---

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

Jakob, Paul,

I have quickly re-read the dane-protocol-10 and the confusion might come
from the fact that we don't explicitly state anywhere that you might
have more TLSA records in the 4.4.

On 1. 9. 2011, at 10:39, yzw_iplab wrote:

> In order to fix it, the first case is the best choice.

I don't believe there's anything to be fixed in the protocol.

It's implicitly stated in this (and following paragraph):

   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.

However I feel this might need little clarification in the DANE protocol
document, explicitly stating that there could be one or more TLSA records
at the same owner.

> I mean the protocol draft should manifest the update process

I believe this should go to the operational document, not into the protocol.

> and it should explain that the client should use all the TLSA RRs got from the DNS response for the authentication (e.g., when the client gets old TLSA RR and new TLSA RR, it should use the two RRs to authenticate the TLS server). When all the TLSA RRs are failed to authenticate the server, the TLS authentication association is unusable. Any one of the multiple TLSA RRs can successfully authenticate the server, the process can be continued.

This is stated in the DANE protocol draft (last paragraph of 4.4):

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

There's nothing as old and new from the client view (e.g. the client has no knowledge about NEW and OLD).

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: [email-masked]
Date: Fri, 2 Sep 2011 22:52:00 +0000

On Thu, Sep 01, 2011 at 08:16:21PM +0200, OndEej SurC= wrote:
> Jakob, Paul,
> I have quickly re-read the dane-protocol-10 and the confusion might comefrom the fact that we don't explicitly state anywhere that you mighthave more TLSA records in the 4.4.
> However I feel this might need little clarification in the DANE protocoldocument, explicitly stating that there could be one or more TLSA recordsat the same owner.

	this sounds problematic to me.  

	"... should use ALL the TLSA RRs..."   - so If I pub 254 TLSA RRs, the client has to use
	ALL of them?   Sounds like a DDoS on the wire to me.

	"OLD and NEW"  - sounds like a use case is being codified in the protocol.

	the presumptive here seesm to be that presented TLSA RRs will only differ in the timestamps.
	i.e. they will be exact matches in all other respects.  Usually, when presented with a
	choice of multiple answers, it is prudent to lay out the tie breaker rules.  The stated rule
	"any one of the multiple TLSA RRs can suthenticate (...) can continue" sounds suspect to
	me.  First In?  Closest Match?  How is the evaluation to be done?

/bill

---

From: Jakob Schlyter <[email-masked]>
Date: Sat, 3 Sep 2011 13:13:10 +0200

> 	ALL of them?   Sounds like a DDoS on the wire to me.

The simple rule is that one matching TLSA (that the client can use) is enough . Once the client finds a match, it MAY ignore the rest of the TLSA records.

	jakob

---

From: [email-masked]
Date: Sat, 3 Sep 2011 11:27:32 +0000

> The simple rule is that one matching TLSA (that the client can use) is enough . Once the client finds a match, it MAY ignore the rest of the TLSA records.

	ok,,, first match.  is that in the spec?

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

---

From: Jakob Schlyter <[email-masked]>
Date: Sat, 3 Sep 2011 13:48:05 +0200

> 	ok,,, first match.  is that in the spec?

Yes.

  "If a match between one of the certificate association(s) and the
   "access_denied" error."

(the definition of "usable", what TLSA records to ignore etc. is defined as well, and is even more clarified in the next version)

	jakob

---

From: Warren Kumari <[email-masked]>
Date: Wed, 7 Sep 2011 18:51:27 -0400

Alrighty…

As part of the new, faster, leaner, meaner approach to working issues I'd like to call consensus on this on Friday 16:00UTC.

Is the (current) below text acceptable (especially after "usable" is clarified in the next version) to the WG?

W

---

From: "yzw_iplab" <[email-masked]>
Date: Thu, 8 Sep 2011 08:51:40 +0800

If there are multiple TLSA RRs (e.g, “If I pub 254 TLSA RRs”--quoted from bmanning’s mail) for a name. The one-by-one comparison approach is not efficient enough. Maybe the lifetime or priority of TLSA RR should be considered for the validation.
If it is not considered in this document, I think it is clear now.

2011-09-08 

yzw_iplab 

发件人： Warren Kumari 
发送时间： 2011-09-08  06:51:34 
收件人： Jakob Schlyter 
抄送： bmanning; yzw_iplab; Paul Hoffman; DANE WG 
主题： Re: [dane] #31: Multiple TLSA records in a response 
 
Alrighty…

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Sep 2011 18:01:46 -0700

> If it is not considered in this document, I think it is clear now.

An implementation can optimize however it wants; the spec should not specify how.

--Paul Hoffman

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 8 Sep 2011 05:09:59 +0200

> If it is not considered in this document, I think it is clear now.

The suggested text (with a small change from Bill) is:

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.

	jakob

---

From: [email-masked]
Date: Thu, 8 Sep 2011 04:10:37 +0000

On Thu, Sep 08, 2011 at 05:09:59AM +0200, Jakob Schlyter wrote:
> > If there are multiple TLSA RRs (e.g, bIf I pub 254 TLSA RRsb--quoted from bmanningbs mail) for a name. The one-by-one comparison approach is not efficient enough. Maybe the lifetime or priority of TLSA RR should be considered for the validation.> If it is not considered in this document, I think it is clear now.
> On the first match between one of the certificate association(s) and theserver's end entity certificate in TLS is found, the TLS client continues theTLS handshake, ignoring remaining certificate associations. If no matchbetween the usable certificate association(s) and the server's end entitycertificate in TLS is found, the TLS client MUST abort the handshake with an"access_denied" error.
> 
> 	jakob
> _______________________________________________dane mailing [email-masked]://www.ietf.org/mailman/listinfo/dane

	i'm ok w/ last calling this text.

/bill

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 8 Sep 2011 08:17:07 -0400

As Steve Kent pointed out earlier, this group has no business with a MUST
there.

If you want to change PKIX processing you have to get consensus in the PKIX
group.

2011/9/7 Jakob Schlyter <[email-masked]>

> > If there are multiple TLSA RRs (e.g, “If I pub 254 TLSA RRs”--quoted from
> bmanning’s mail) for a name. The one-by-one comparison approach is not
> efficient enough. Maybe the lifetime or priority of TLSA RR should be
> considered for the validation.

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

---

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

> If you want to change PKIX processing you have to get consensus in the PKIX

Steve's message was slightly unclear.

PKIX is only "authoritative" for PKIX certificate path validation,
(section 6.x of rfc5280) and the result from that check is a
binary answer:
     (0) certificate path validation failed
     (1) certificate _not_ known to be invalid

  or (0) negative confirmation
     (1) absensence of negative confirmation

But whether an "application caller" performs other or addtional
checks or comparisons on any certificate from the certification
path or any attributes thereof, before it considers a TLS server
certificate acceptable, is purely at the discretion of that
application caller and PKIX has no say in that.

The matching performed on name-related attributes by rfc6125
(and rfc2818 before that) are outside of the scope of PKIX,
similar to several checks that DANE defines.

-Martin

---

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

I would actually like to propose a slightly different approach here.

If you look at the use cases document, there are at least two different uses for multiple TLSA records.  The "Roll-Over" paragraph discusses having two certificates active at once, and the "Combination" paragraph discusses having multiple constraints on a certificate, e.g., to allow a domain-operated CA and no other.  The "Combination" case cannot be met with the text under discussion, since only one association is ever considered.

As an alternative, I would propose that we create a simple way to combine TLSA associations in a kind of disjunctive normal form.  Currently, TLSA records are combined with an "or" operation -- the whole matches iff any one matches:
  RR1 || RR2 || RR3 || RR4
It would be nice to be able to say "AND these records together", so that you could have something like the following:
  RR1 || (RR2 && RR3) || RR4
That way you could still do "first match", but that match might be across a couple of records.

Proposal: Add a "group id" (gid) field to the TLSA record format.  This field doesn't need to be long, one octet would suffice, and change the matching logic to the following:
"
When there more than one TLSA record for a target domain, a certificate matches if it matches all of the records within any record group.  Record groups are identified by the GID field; a group is comprised of all records with the same GID value.  To determine whether a certificate is a TLSA match for a domain, it SHOULD execute the following steps:
1. Gather TLSA records into groups by GID
2. For each group
   - Determine whether the certificate matches all records in the group
   - If the certificate matches, then return true
   - If the certificate does not match, then process the next group
3. If no group matches, then return false
"

The current situation can be replicated by assigning each record a distinct GID.

This algorithm does require the client to process all TLSA records, but only to the extent of parsing them and pulling the GIDs.  That's a much cheaper operation than actually doing the matches.

--Richard

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Sep 2011 08:54:44 -0700

> This algorithm does require the client to process all TLSA records, but only to the extent of parsing them and pulling the GIDs.  That's a much cheaper operation than actually doing the matches.

While this change does meet the "combination" use case, it also makes the protocol more complex. It requires that domain administrators who don't care about combination still pick a group ID (even if it is 0). Is the use case actually worth the additional complexity? If so, I think that Richard's proposal is probably the least complex way to implement it.

--Paul Hoffman

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 8 Sep 2011 12:06:05 -0400

> While this change does meet the "combination" use case, it also makes the protocol more complex. It requires that domain administrators who don't care about combination still pick a group ID (even…

If there's worry about defaults, you could certainly create a "no group" special case (e.g., GID==0), and update the processing so that "no group" things are handled on an "individual first match" basis (i.e., the current rules) (i.e., each record as its own group).

--Richard

---

From: "yzw_iplab" <[email-masked]>
Date: Fri, 9 Sep 2011 08:41:49 +0800

1)It is unclear what the definition of Group is.
2)For the TLS server, it only maintains one certificate at a time. Although the certificate associations are grouped, they still should be checked one by one.
3)”A certificate matches if it matches all of the records within any record group”, what’s the meaning and purpose of this?
2011-09-09 

yzw_iplab 

发件人： Richard L. Barnes 
发送时间： 2011-09-08  22:30:10 
收件人： Warren Kumari 
抄送： Jakob Schlyter; yzw_iplab; bmanning; Paul Hoffman; DANE WG 
主题： Re: [dane] #31: Multiple TLSA records in a response

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 9 Sep 2011 09:07:10 +0200

> While this change does meet the "combination" use case, it also makes the protocol more complex. It requires that domain administrators who don't care about combination still pick a group ID (even…

I do not believe that supporting "combination" is worth the additional complexity and I urge the WG to keep DANE as simple as possible.

	jakob

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 9 Sep 2011 09:29:14 +0200

> I do not believe that supporting "combination" is worth the additional complexity and I urge the WG to keep DANE as simple as possible.

+1

---

From: Leif Johansson <[email-masked]>
Date: Fri, 09 Sep 2011 10:24:00 +0200

> Proposal: Add a "group id" (gid) field to the TLSA record format.  This field doesn't need to be long, one octet would suffice, and change the matching logic to the following:

Woops - my featureitis detector just went off. Before you know
it TLSA is the new NAPTR.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 9 Sep 2011 11:17:10 -0400 (EDT)

> I do not believe that supporting "combination" is worth the additional complexity and I urge the WG to keep DANE as simple as possible.

+1 We don't want DANE to become PKIX.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 9 Sep 2011 13:38:17 -0400

+1

This stuff is way too complex to put into DNS.

On Fri, Sep 9, 2011 at 3:07 AM, Jakob Schlyter <[email-masked]> wrote:

> > While this change does meet the "combination" use case, it also makes the
> protocol more complex. It requires that domain administrators who don't care
> about combination still pick a group ID (even if it is 0). Is the use case
> actually worth the additional complexity? If so, I think that Richard's
> proposal is probably the least complex way to implement it.
>
> I do not believe that supporting "combination" is worth the additional
> complexity and I urge the WG to keep DANE as simple as possible.
>
>        jakob
>

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 9 Sep 2011 13:26:47 -0700

While I believe that this may end up being a feature that needs to be
supported.  I believe that it would be better to have a new cert type that
said how to do combinations rather than having it baked in at a low level.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jakob Schlyter
> Sent: Friday, September 09, 2011 12:07 AM
> To: Paul Hoffman
> Cc: DANE WG
> Subject: Re: [dane] #31: Multiple TLSA records in a response
> 
> protocol more complex. It requires that domain administrators who don't
> care about combination still pick a group ID (even if it is 0). Is the use
case
> actually worth the additional complexity? If so, I think that Richard's
proposal
> is probably the least complex way to implement it.
>

---

From: Warren Kumari <[email-masked]>
Date: Wed, 14 Sep 2011 13:45:34 -0400

Alright, we are calling this....

We delayed the calling for a few days (5ish) to confirm that Martin's interpretation was reasonable[0] ( http://www.ietf.org/mail-archive/web/dane/current/msg03341.html ) - having heard nothing to the contrary we are assuming it is.

The consented text was:

We are also calling Richard's suggestion on adding a "group id" (gid) field to the TLSA record format to allow for combinations ( http://www.ietf.org/mail-archive/web/dane/current/msg03345.html ).
While this does provide additional flexibility, the consensus is that it adds too much additional complexity and so is not being included at the moment[1].
I *may* open (and then close) an issue in the tracker to track this...

W

Footnotes with no hats:
[0]: I think it is, but wanted to give folk (including Dr Kent) time to respond.
[1]: I think that this is an interesting idea, and if (heaven forbid) we end up with a DANEbis or V2 we may want to consider it then -- or Jim's suggestion ( http://www.ietf.org/mail-archive/web/dane/current/msg03352.html ) or something).

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Sep 2011 21:47:26 +0200 (MEST)

> certificate in TLS is found, the TLS client MUST abort the handshake with an

I'm slighlty confused by this specific error message text "access_denied".
Traditionally, an "access_denied" error is not something that one
inflicts on oneself, but used for situations with two distinct entities,
where the other denies access, and the entity that receives that error
has no means to ignore or override this.

To me, the situation looks like a "server certificate DANE validation failed"
error.  And DANE-aware implementations MUST fail (by default) when
encountering this error.  Implementations MAY offer a means to continue
in spite of this error, but if they do, they MUST ensure with reasonable
confidence that the consumer of the technology is fully aware of the risks
involved with continuing in spite of this error.

btw. would it be OK to be more elaborate about DNS zones that
use DNSSEC but do not contain any TLS records for a server host name.
currently it reads:
                             If the application receives zero usable
   certificate associations, it processes TLS in the normal fashion.

How about something along these lines:

                             If the application receives zero usable
   certificate associations (i.e. if zero TLSA records are returned
   for the server host name), then no additional checks based on this
   specification are performed on the server certificate (chain),
   and the normal TLS server certificate validation and server
   endpoint identification applies.

I'm slightly confused by the term "application" in the above sentence,
because it really refers to an implementation of this specification itself
rather than some application calling this implementation.

-Martin

---

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

> has no means to ignore or override this.

To me, that is what is happening when the domain owner says "here is the certifying information" and it is unusable. The definition in the TLS spec for access_denied is:
      A valid certificate was received, but when access control was
      applied, the sender decided not to proceed with negotiation.  This
      message is always fatal.
If you have a different fatal TLS error that you  think would be better, that would be well worth discussing. In the end, however, the fact that the TLS error is fatal is all that is relevant.

> encountering this error.  

You are proposing a new TLS fatal error condition. I think that modifying the TLS protocol is outside the power of this WG.

> Implementations MAY offer a means to continue

This was discussed earlier on the mailing list, I believe, and the consensus was to make the failure fatal without allowing continuation.

>   endpoint identification applies.

I don't see how that extra wording helps. "processes TLS in the normal fashion" is shorter and clearer.

> rather than some application calling this implementation.

We fully disagree here. Applications do not "call this implementation": they incorporate the additional rules as part of the implementation.

--Paul Hoffman

---

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

Paul Hoffman wrote:
> Martin Rex wrote:
> To me, that is what is happening when the domain owner says
> "here is the certifying information" and it is unusable.
> The definition in the TLS spec for access_denied is:

That seems to be confusing issues.  The domain owner is some third party,
it is neither the TLS client nor the TLS server, so no parts of the
TLS spec really apply to the situation.  The TLS spec defines the
fatal alert (49) "access_denied" that a TLS peer can send prior to closing
the connection -- but there is *NO* requirement in TLS that the connection
must be aborted when some particular validation of the peer certificate
fail or can not be performed.

All of the TLS specs in existance are very clear on this aspect, see
last sentence of Section 1 Introduction of all TLS specs:

   the decisions on [...] how to interpret the authentication certificates
   exchanged are left up to the judgment of the designers and
   implementors of protocols which run on top of TLS.

>
> If you have a different fatal TLS error that you think would be better,
> that would be well worth discussing.  In the end, however, the fact that
> the TLS error is fatal is all that is relevant.

Maybe it is just not sufficiently clear what is meant by this.

This specification describes the behaviour of a "DANE client", that
an application employs in helping to verify the server certificate (chain)
of a TLS server -- exactly as the last sentence of section 1 Introduction
of the TLS spec defines it.  This DANE client sits alongside with
an implementation of rfc6125 (or rfc2818) for traditional TLS (server)
endpoing identification between application and TLS implementation.

When the application client decides that it does not accept the server
certificate, then the client's TLS implementation should close the
connection with a fatal access_denied(46) alert, independent of
why the client didn't accept the certificate, whether it was a
pkix validation failure, whether it was an rfc6125/rfc2818 matching
failure, whether it was a DANE matching failure, whether it's one
of those rare applications clients that matches a policy OID or
whether the client performed and failed some other fancy checks
on the server certificate chain.  That is nothing we should
or have to specify in DANE.

What DANE should specify is API level behaviour, but that is
clearly distinct from what TLS does on the wire.

Whether DANE is called directly by the TLS protocol stack or
indirectly by the application, and whether the application
offers the user options to override the DANE validation result
before directing the TLS protocol stack to either abort or continue
the handshake is at the discretion of the application caller.

> normal fashion" is shorter and clearer.

It may be shorter and clearer to you, but it is technically plain wrong.

As I said, TLS is very explicit that making sense of the certificates
of the communication peers is entirely at the discretion of the
application caller.  When using a TLS extension like rfc6091
then the handshake would be completely PKIX-free.

What "normally" happens is a TLS server certificate validation
and a server endpoint identification performed at the discretion
of the application.   While there may be TLS implementations where
the TLS implementation can perform those checks on behalf of the
application ("added value"), the protocol architecture is very
clear that this is a function of the application and _NOT_ a
function of the TLS implementation.

> We fully disagree here. Applications do not "call this implementation":
> they incorporate the additional rules as part of the implementation.

Yup, it seems like we disagree.

I really expect seperate DANE client modules that may be distributed/part
of the TLS software distribution that will perform the check on behalf
of the application.

I'm used to specification that refer to implementations of itself
with terms like "compliant implementations", and use the term
"application" to any code higher up in the software stack from
their perspective.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 15 Sep 2011 16:36:46 -0500

On Thu, Sep 15, 2011 at 3:07 PM, Paul Hoffman <[email-masked]> wrote:

> andshake with an
> You are proposing a new TLS fatal error condition. I think that modifying
> the TLS protocol is outside the power of this WG.

We are agreed on that, but what we are not agreed on is what constitutes
modification of the TLS protocol.

RFC 5246 has the word 'must' 168 times. I have just been through them all
and cannot find any MUST that refers to rejecting a cert. The string OCSP
does not occur, CRL occurs only once and that is in the PKIX reference.

Martin uses the phrase 'DANE-aware implementations MUST'. That is a much
weaker statement that the one you are proposing which requires ALL TLS
clients to abort the handshake.

>> certificate in TLS is found, the TLS client MUST abort the handshake with
an

Were DANE to become an Internet Standard it would be an IETF criteria, not a
DANE one.

Thus the proposal as written is a modification of the TLS protocol and
beyond the scope of this Working Group.

The DANE WG can define what it is to be DANE aware, it MUST NOT be allowed
to define what is acceptable behavior for a TLS client.

The WG applied for a charter on the basis that it would produce a mechanism
for publishing keys:

"This working group will develop mechanisms for zone operators to
present bindings between names within their control and public keys,..."

Nowhere do I see a statement to the effect that the WG will impose
requirements on client implementations, on the contrary:

"The solutions specified by this working group rely upon the security of
the DNS to provide source authentication for public keys. The
decision whether the chain of trust provided by DNSSEC is sufficient to
trust the key, or whether additional mechanisms are required to determine
the acceptability of a key, is left to the entity that uses the
key material."

Given the approach that the WG has taken to this work I suggest that the ADs
consider an applicability statement to clarify this situation.

DANE was sold to the IETF on the basis that it would provide a means of
using DNSSEC to publish keys. Instead it has developed a spec whose
principle design objective has been to restrict use of keys issued under
PKIX.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 15 Sep 2011 18:33:51 -0400

On Sep 15, 2011, at 5:36 PM, Phillip Hallam-Baker wrote:

> We are agreed on that, but what we are not agreed on is what constitutes modification of the TLS protocol.
> 
> RFC 5246 has the word 'must' 168 times. I have just been through them all and cannot find any MUST that refers to rejecting a cert. The string OCSP does not occur, CRL occurs only once and that is in the PKIX reference.
> 
> 
> 
> 
> Martin uses the phrase 'DANE-aware implementations MUST'. That is a much weaker statement that the one you are proposing which requires ALL TLS clients to abort the handshake.
> 
> 
> > Warren Kumari wrote:
> >>
> >> The consented text was:
> >>
> Were DANE to become an Internet Standard it would be an IETF criteria, not a DANE one. 
> 
> Thus the proposal as written is a modification of the TLS protocol and beyond the scope of this Working Group. 
> 

<no hat>
I had interpreted that to mean for things doing DANE -- non-DANEy things would not be looking for TLSAs, be performing most of this process, etc, but I'd be interested to hear if my interpretation is not what was intended.
</no hat>

> 
> The DANE WG can define what it is to be DANE aware, it MUST NOT be allowed to define what is acceptable behavior for a TLS client.
> 
> The WG applied for a charter on the basis that it would produce a mechanism for publishing keys:
> 
> Nowhere do I see a statement to the effect that the WG will impose requirements on client implementations, on the contrary:
> 
> the DNS to provide source authentication for public keys. The decision whether the chain of trust provided by DNSSEC is sufficient to trust the key, or whether additional mechanisms are required to determine the acceptability of a key, is left to the entity that uses the key material."
> 

This is somewhat ambiguous (and I'm low on coffee, so thinking is hard) --  that says "is *sufficient* to trust the key" (emphasis added) which sets the bar high, not that this cannot be used to explicitly NOT trust the key.
But, as I said, I'm low on coffee... 

> 
> Given the approach that the WG has taken to this work I suggest that the ADs consider an applicability statement to clarify this situation.
> 

Seems more than fair -- Stephen / Sean, please let us know if we are overstepping our charter....

> DANE was sold to the IETF on the basis that it would provide a means of using DNSSEC to publish keys. Instead it has developed a spec whose principle design objective has been to restrict use of keys issued under PKIX.
> 
> 
> 
> --

---

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

> modification of the TLS protocol.

I see DANE as a useful addition for TLS clients, and I think it would be
very good to include it as a utility function available to application
callers along with TLS software distributions, but I do not consider
it part of TLS itself (neither do I consider rfc6125/rfc2818 part of TLS).

> beyond the scope of this Working Group.

I would OK to discuss this is someone added an
"Updates: 5246" or "Obsoletes: 5246"  to the current document.
Currently, it looks more like wordsmithing to me and premature
to get upset about it.

> to define what is acceptable behavior for a TLS client.

I do not believe that an  s/TLS client/DANE-aware TLS client/g
is necessary on the document.  A clarifying statement in the
introduction might be sufficient.

> principle design objective has been to restrict use of keys issued under

DANE is used to distribute DNSSEC-signed assertions the validity
of public keys (including public keys embedded in X.509 certs)
of TLS servers.  I personally believe that DANE is still perfectly
within its charter.

Being able to distribute independent confirmations for TLS Server
certificates issued under the traditional TLS X.509 PKI is a
desperately needed functionality as has been painfully demonstrated
several times resulting in some 200.000 virtual fatalities.

While the TLS server certificate mis-issuance event at Commodo created
a significant security threat, the most recent event at DigiNotar
was *MUCH* worse.  Sort-of an "extinction-level event" for the
TLS X.509 PKI as we know it.  Asked about why they had not revoked
the fraudulent Google certificate, DigiNotar responded "we were not aware
that this certificate had been issued".

DANE could have easily stopped that Google cert problem dead in its tracks.

PKIX has no current means to prevent it, even for clients that
do OCSP plus hard fail (and both of these are serious problems,
OCSP by RP for privacy, and OCSP hard fail for robustness and performance).

-Martin

---

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

The proposed language is unequivocal. Clients MUST abort the TLS handshake.

Tha changes the TLS conformance as written.

Your language, DANE aware is still ambiguous. The language would have to be 'DANE compliant' to make it clear that support for the DANE profile is an option and not an IETF mandate.

Support for DANE at any level is going to be optional. So putting a MUST for the most controversial part of the spec seems like a bad move for adoption in any case.

From a systems point of view, aborting the connection is at best going to protect one user. Alerting some party to the possibility of a policy violation is actually more important.

Sent from my iPad

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 15 Sep 2011 18:18:56 -0700

> Martin uses the phrase 'DANE-aware implementations MUST'. That is a much weaker statement that the one you are proposing which requires ALL TLS clients to abort the handshake.

It is assumed in IETF protocols that only systems that implement the protocol actually care about the protocol. Your interpretation that RFC X might affect RFC Y without saying so is "interesting", and not supported by anything published the IETF that I know of.

Having said that, your proposed change (adding "DANE-aware" to the spec) seems harmless. Unless we hear objections, we'll make that change in the next draft.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 15 Sep 2011 21:44:25 -0500

On Thu, Sep 15, 2011 at 8:18 PM, Paul Hoffman <[email-masked]> wrote:

> It is assumed in IETF protocols that only systems that implement the
> protocol actually care about the protocol. Your interpretation that RFC X
> might affect RFC Y without saying so is "interesting", and not supported by
> anything published the IETF that I know of.
>

Given that you have on previous occasions led me to believe that you were
prepared to accept a compromise which turned out not to be the case, I think
it is in the interest of the group that there is total clarity on this
point.

Having said that, your proposed change (adding "DANE-aware" to the spec)
> seems harmless. Unless we hear objections, we'll make that change in the
> next draft.

Actually that was Martin's formulation. I suggested DANE-compliant.

DANE-aware might be taken to imply that if a client has the ability to check
for DANE compliance then it is obliged to do so in every case.

I still think that mandating aborting the connection is inappropriate. That
is a trust decision for the client. In my (admittedly brief) reading on the
TLS spec today we do not appear to mandate that a client abort a connection
if a cert is invalid or revoked.

It is appropriate for a protocol standard to define when a security policy
violation (e.g. against a DANE record) has occurred and state the
consequences. Mandating a particular response is not appropriate.

It is highly unlikely that browser implementations are going to get
comfortable enough with DNS based security policy records to switch on
hardfail immediately. If hardfail is mandated the likely outcome is going to
be that the industry chooses other approaches.

---

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

On 2011-09-15 7:44 PM, Phillip Hallam-Baker wrote:
> It is appropriate for a protocol standard to define when a security
> policy violation (e.g. against a DANE record) has occurred and state the

Mandating client behavior is the only way to avoid lack of 
interoperability.  In this case, mandating hard failure is also the only 
way this spec does any damn good relative to the status quo, security-wise.

> hardfail immediately. If hardfail is mandated the likely outcome is
> going to be that the industry chooses other approaches.

I do not speak for Mozilla, but I am one of the guys who might be 
implementing DANE for Mozilla, and from my perspective, DANE ceases to 
be worth bothering to implement if it doesn't mandate hard failure. 
You're probably going to turn around and say it's perfectly within my 
power to code in hard failure even if the spec doesn't mandate it, but 
the thing is, if it's not a mandate, *some* browser is going to not do 
it, and then people will demand that their users switch to that browser 
rather than fix their sites, and the entire thing becomes worthless.

In other regards, I mostly don't care what we have to do to avoid 
treading on the TLS and PKIX working groups' toes -- but I will fight 
tooth and nail for that one MUST.

zw

---

From: John Gilmore <[email-masked]>
Date: Thu, 15 Sep 2011 23:18:52 -0700

> principle design objective has been to restrict use of keys issued under

DANE's certified keys would be useless if any of six hundred
untrustworthy CA's anywhere in the world could "issue under PKIX" a
man-in-the-middle certificate that every browser would accept in
preference to the DANE certified key.

You know this, Phillip; you aren't stupid.  So please stop trolling
us.  Too-obvious efforts like this one are making us better at
ignoring you and just getting the work of the committee done.

The PKIX CA model is dead.  Two major security incidents have killed
it.  One was a "warning shot", and the other involved a totalitarian
country breaking into a CA in another country, issuing itself more
than 500 fake certs, and using them to surveill their entire
population's "https" web accesses to major infrastructural sites, for
some as yet undetermined number of days or weeks.

The world is damn lucky that IETF *has* an effort already in progress
to design and deploy a replacement.  Now that every bad guy in the
world knows, by reading the newspaper, how vulnerable "secure" web
sites are when "secured" by PKIX, nothing will prevent more and more
serious security violations, ending only when the Internet community
completely stops depending on the PKIX CA model.

If we are lucky, and smart, we'll get the replacement rolled out
before the Internet user community completely loses faith that that
"https:" prefix and padlock image has any meaning at all.

	John

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 16 Sep 2011 10:25:21 +0200

> DANE was sold to the IETF on the basis that it would provide a means of using DNSSEC to publish keys. Instead it has developed a spec whose principle design objective has been to restrict use of ke…

I do not agree on this statement. DANE as always been "sold" as a method of limiting trust in the current public key infrastructure - either by constraining trust of CA issued certificates (usages 0 and 1) or by introducing trust to self-signed certificates (usage 2).

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 16 Sep 2011 06:31:00 -0500

I take objection to the objection in the first line

If you want me to bother to read the rest of your post you will withdraw it
immediately.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 16 Sep 2011 06:34:01 -0500

On Fri, Sep 16, 2011 at 3:25 AM, Jakob Schlyter <[email-masked]> wrote:

> I do not agree on this statement. DANE as always been "sold" as a method of
> limiting trust in the current public key infrastructure - either by
> constraining trust of CA issued certificates (usages 0 and 1) or by
> introducing trust to self-signed certificates (usage 2).

That is simply not true.

While it is arguable that the charter could be interpreted as permitting
usages 0 or 1 it does not state that they are the objective.

The only reason that usage became apparent at all was that I rooted it out
from the original draft.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 16 Sep 2011 07:01:04 -0500

On Fri, Sep 16, 2011 at 12:21 AM, Zack Weinberg <[email-masked]>wrote:

> interoperability.  In this case, mandating hard failure is also the only way
> this spec does any damn good relative to the status quo, security-wise.

That is simply not true.

The mandate is to BREAK. Explain which parties will not be able to function
as a result of the client rather than the domain name holder making the
choice.

> implementing DANE for Mozilla, and from my perspective, DANE ceases to be
> worth bothering to implement if it doesn't mandate hard failure. You're
> probably going to turn around and say it's perfectly within my power to code
> in hard failure even if the spec doesn't mandate it, but the thing is, if
> it's not a mandate, *some* browser is going to not do it, and then people
> will demand that their users switch to that browser rather than fix their
> sites, and the entire thing becomes worthless.
>

The IETF does not have the power to mandate behavior in that fashion.

What you are proposing here is that the specification mandate a behavior so
that Microsoft, Google etc. are required to comply with your policy
decision.

That is not how the IETF works. When it has attempted to make such calls in
the past the vendors have simply ignored them. As a result we now have
firewalls.

When the IETF has overstepped the mandate the vendors are willing to allow
it they have formed alternative forums. I was involved in the formation of
W3C and OASIS, I saw the politics there first hand.

The problem you identify with 'interoperability' applies equally to the
decision to deploy DANE in the first place. You will find it very hard to
get your management to agree to deploy a DANE unless all the other browser
vendors are considering it.

Some years ago the industry was pretty much willing to follow Microsoft's
lead on this type of issue and Microsoft was willing to be the leader. Over
the past five years they have been much less willing to lead and no other
company has stepped up to take that role.

In other regards, I mostly don't care what we have to do to avoid treading
> on the TLS and PKIX working groups' toes -- but I will fight tooth and nail
> for that one MUST.

 Even if the result of doing so was that there were no compliant
implementations?

The IETF is not a process where a group of random people get together and
decide what to order the vendors what to do.

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 16 Sep 2011 14:50:21 +0200

Phil,

If you do not agree with the current semantics of TLSA (which implements restriction only), I suggest you provide some proposed changes (i.e., text for the draft) so we can discuss that.

	jakob

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 17 Sep 2011 01:28:17 +1200

Phillip Hallam-Baker <[email-masked]> writes:
>> > For me, DANE does X!
>> Well, for me, DANE does Y!
>
> That is simply not true.

As far as I can tell, DANE was always sold as magic pixie dust, with the 
colour of dust varying depending on who was doing the selling (or buying).  
The only consistent part of the sales pitch was "DANE is not PKIX".  Perhaps 
if everyone could agree on that point, we can then each choose our own 
preferred colour of dust.  I choose fine red dust, the consistency of talcum
powder.

Peter.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 16 Sep 2011 11:02:11 -0500

Remove the MUST abort the connection and replace with 'a DANE security policy violation has been detected.

Then add a section headed "responding to a DANE security protocol violation" and first state the consequeces (either the security policy statement is in error or the channel is compromised) and list the possible client responses

These include :

* abort the connection
* notify some party that the violation has been detected
* continue with indication that connection is compromised

At the moment we do not even have hardfail for expired certs, let alone revoked.

There is a much higher chance of having abort respected if it is an idependent option. But even then it is something the CAs have been asking for for fifteen years, something most of the security guys at the browsers would likely do if it was their sole choice. But it is not an argument the ultimate decision makers are likely to accept even now.

If we had had hardfail on revoked certs there would not have been a relying party issue with the first breach. So why is there this pretense that the only part of the system that is at fault here are the CAs? Sure that is what we signed up for, but that does not change the fact that the significant change you are proposing here is in the BROWSER security model, the change to hardfail. 

The second breach resulted in the CA concerned being shut down completely. I don't know what VASCO paid but they almost certainly took at least a five to ten million dollar hit. 

It is OK to beat on CAs. That is what we signed up for. I do not see ICANN signing up for the same program. Who is going to respond when this new mousetrap you are proposing also fails? Not ICANN, that is for sure. The only party with really solid crypto background is VeriSign and some of the other top tier registries. But their business model is thin registry. The parts of the system that are responsible for customer management are the registrars. And they get their crypto management input from the CAs.

Who audits this mousetrap? If you dont think you need audits then you don't understand the problem. Not that auditors are a panacea, they dont guaratee compliance with policy, the policy may be inadequate. But if you dont have auditors you can guarantee that your policy is going to be breached.

Contrary to what some here think. DANE does not change the model. You merely force a game of musical chairs on everyone and the result would be a system that is more complex and has more points of failure. 

Sent from my iPad

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 16 Sep 2011 10:22:20 -0500

That is not my choice.

Glimore wants us to swap the old pixie dust for some new dust. 

I want to have a layer of the new dust on top of the old.

Those are very different approches. Gilmore is arguing that the respose to the breach should be to throw away the system we have built over the past twenty years and replace it with a new syntax and a design that merely replaces one set of trust providers with another set that have not even comitted to provide third party trust services.

We do not know the failure modes of the ICANN-DANE trust system yet. We do know that they are going to face the same risks, what we do not yet know is what the threats will be. I don't think I am the only person who will object to the idea of responding to a breach with a leap into the unknown.

This is going to be a high wire tight rope act however it is done and whoever does it. It seems a lot easier until you try it. You can suggest changing the performer, but who do you think is going to listen? Better to build a net. Or several nets.

Heck half of you here accused me of hype and scaremongering when I said the threat came from the Iranian government. Anyone still want to argue that we should believe TehranBob on this? If so how did TehranBob redirect the entire Iranian Internet as well? How come he isn't dacing on the end of a crane for doing so? How could the Iranian govt know he isn't Mossad or CIA?

The claim that there are 600 cas is not true. There are 600 RAs of which only about 20 were public RAs. The issue that seems to have allowed them to avoid audit was that there was no distinction made between a validating RA (being essentially a public CA minus signing) an an enterprise RA. 

This is being fixed. I expect that the browser providers will be requiring audits of all validating RAs. This will probably mean that validating RAs disappear completely as it appears that the audit was a bigger deterrent to becoming a CA than the signing part.

But it is still a fact that there was never 600 places you could go to get a cert for an arbitrary domain.

One thing that this dicussion has raised is that the CA world should probably invite the DNS people to some of the meetings we are having to discuss the attacks and the response.

Sent from my iPad

---

From: Paul Wouters <[email-masked]>
Date: Fri, 16 Sep 2011 12:57:56 -0400 (EDT)

> The second breach resulted in the CA concerned being shut down completely. I don't know what VASCO paid but they almost certainly took at least a five to ten million dollar hit.

This comment implies that the current CA system is good and free market ideals
are the right governing system here, and bad CAs will lose money and die out, and
good CAs make money and remain.

Unforutnately, we do not know how many Iranians have been arrested, tortured or
murdered based on Diginotar's and PriveWaterhouseCoopers negligence. And the free
market will never take those lives into account.

In fact, we don't even know if these things happened in the past WITHOUT any
market punishment, because people simple did not know CAs were compromised.
It is only thanks to Adam Langley and the Google Chrome people that we know
this now.

This is no longer your mothers playground. We're talking about lives, not money.

> Who audits this mousetrap?

> Contrary to what some here think. DANE does not change the model. You merely force a game of musical chairs on everyone and the result would be a system that is more complex and has more points of…

Mostly, the individual companies involved. On top of them, the Registrars and the Registry.
That's a whole lot less then in the CA model. I'm sure we will see DNS hacks, Registrar and
Registry compromises. DANE is not the silver bullet, but the CA system is shooting soap bubbles.

> Sent from my iPad

Ironically, sent from a device that still has Diginoar's certificate on it.
(AFAIK only OSX got the updates, not iOS)

Paul

---

From: Martin Rex <[email-masked]>
Date: Fri, 16 Sep 2011 23:35:37 +0200 (MEST)

> tooth and nail for that one MUST.

I prefer a "MUST (by default)" (or MUST ... UNLESS) to SHOUld,
e.g. something like the current scary page in Web Browsers for
PKIX server cert validation failures, but that still provides
the user an option to override.

An unconditional MUST would not make sense in combination with
optional TLSA types that clients not implementing them will simply
ignore (falling back to traditional PKIX server cert validation and
server endpoint identification).

-Martin

---

From: John Gilmore <[email-masked]>
Date: Sat, 17 Sep 2011 16:02:22 -0700

> Gilmore is arguing that the respose to the breach should be to throw
> away the system we have built over the past twenty years and replace
> it with a new syntax and a design that merely replaces one set of
> trust providers with another set that have not even comitted to
> provide third party trust services.

That's quite a run-on sentence.  Let's see:

Gilmore is arguing that the main failing of the CA system is that it
allows ANY CA, worldwide, to subvert the security of ANY "secure"
website by aiding an undetected MITM attack.  DNSSEC/DANE limits the
number of parties who can do that, to only the website's domain
providers.  It's along the lines of "put all your eggs in one
basket, and guard that basket well".

Gilmore is arguing that domain name users (including all web sites)
must already trust their domain registrar and domain registry.  Either
of those parties could trivially aid in a MITM attack, merely by
changing the "NS" or "A" records of the domain.  So far we have only
seen minimal attacks of this sort (mostly perpetuated by government
agencies and courts, acting as censors, in the open, and with
legitimate avenues of appeal to higher courts).  If in general, domain
registrars and registries cannot be trusted, the CA system is fatally
broken too, since it too depends on domain names.

> The claim that there are 600 cas is not true. There are 600 RAs of
> which only about 20 were public RAs.  ...  But it is still a fact
> that there was never 600 places you could go to get a cert for an
> arbitrary domain.

What is implied here is that only about 20 places could provide false
keying material for any arbitrary website (e.g. "google.com").  That
implication, I believe, is false; 600 could.

What he actually seems to have said is that you can only ASK 20 of
them to do so through a public interface (like their website).  But I
believe that if you break into them, or subvert their employees
through bribery, blackmail, physical coercion, etc, any of the 600
are capable of providing false keying material for any website.

If software authors of TLS-based programs, like browsers, are
preparing to stop trusting 580 of those key-certifiers, then that's a
positive step, but it's no reason to abandon the DANE effort.

	John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 18 Sep 2011 00:10:59 -0400

That is quite a lot of wild claims.

You clearly don't understand what the capabilities of the RAs in question
are. You keep repeating an assertion that is false, so why on earth should
the Internet trust you?

---

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

Hi all,

could we please get back to technical discussion?

The discussion seem to get very hot and personal, please could we
_all_ try to stick with the problems opened in this thread (I would 
like to fill them as separate issues) and not discuss CAs, RAs, Iran
and other political and human rights stuff?

We (Warren did) already asked our ADs (Ccing them again just to be sure)
if we are overstepping our charter here, so let's wait if they respond.
With my chair hat on, I don't think so, but their opinion may differ
and it doesn't make sense to reiterate the arguments before we have their
opinion.

I don't think this discussion helps any progress of the DANE protocol,
so if we can stop it now and here (in the mailing list) I would really
appreciate that.

Thank you,

---

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

On Fri, 2011-09-09 at 09:07 +0200, Jakob Schlyter wrote:
> > While this change does meet the "combination" use case, it also
> makes the protocol more complex. It requires that domain
> administrators who don't care about combination still pick a group ID
> (even if it is 0). Is the use case actually worth the additional
> complexity? If so, I think that Richard's proposal is probably the
> least complex way to implement it.
> 

Let me first point out that the "combination" referred to here is the
same "conjunction" as in ticket 27.

-1.  I agree that conjunctions like "EE certificate match && CA
certificate match" do not have enough substantive benefit to justify the
feature.  But conjunctions also provide a natural solution for:

- Restrictive assertions (#25): "traditional && my_DANE_predicates".

- Full hash agility (#33): put all the hashes of the same cert in a
conjunction and let the client check one or more of them as it wishes.

I agree that the group ID is a little ugly, and would instead propose to
concatenate all the predicates of each conjunction ("profile") in a
single RR.  Then the RRset would be a pure disjunction of the RRs, in
the same spirit as the A RRset.  Rollover would involve addition or
removal of whole RRs, which is more intuitive to the DNS admin who is
not a DANE expert.

I regret coming late to this discussion, due to limited Internet
connectivity for the last two weeks.  I imagine my vote won't flip the
consensus, but please note it.

-- 
Matt

---

From: Warren Kumari <[email-masked]>
Date: Wed, 21 Sep 2011 10:44:19 -0400

The chairs have conferred and have decided to call this -- while it is not unanimous, we do see strong consensus for the "MUST" behavior described in the text (and our ADs (CCed) have not informed us that we are overstepping our charter[0]).

In order to address Phillip's concerns regarding the "TLS client" wording, we ask the authors to modify the text to clarify that the behavior described in the DANE protocol doc only applies things actually doing DANE and to post a new version of the draft with this clarification.

Some discussions occurred regarding the specific error to returned ("access_denied") and meaning of "application"  -- no better error / text was provided and so that is how the text currently stands.

Warren and Ondrej.
[0]: Obviously, if they do, we'll reopen this issue / discussion.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 21 Sep 2011 12:18:22 -0400

This will be revisited then in IETF last call.

Sent from my iPhone

---

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

> This will be revisited then in IETF last call.

Noted.
W