Subject: [keyassure] PROPOSAL: Revision of DANE client requirements

From: Zack Weinberg <[email-masked]>
Date: Mon, 28 Mar 2011 09:46:50 -0700

I'd like to propose some revisions to the text of DANE.
Specifically, I want to make the requirements upon TLS clients that
implement the spec clearer, and I also want to consolidate them in one
place.  The current draft
(http://tools.ietf.org/html/draft-ietf-dane-protocol-06) scatters
client requirements all around the text, and it is IMO a bit too vague
about exactly what *is* a requirement.  I want to avoid a situation
where not all clients interpret TLSA records the same way, and I also
want to avoid a situation where a site administrator might be confused
about the effects of adding TLSA records to their zones.  With a few
exceptions, I believe all my proposed changes are strictly editorial
-- that is, I have not removed or added any requirements upon TLS
clients, I have just made it clearer what they are.

The exceptions are: First, it is not clear to me whether the present
intent of the spec is that a TLSA record for site S specifying
certificate X forbids a compliant client from proceeding with the
handshake if it receives certificate Y.  I think the answer to this
question must be an unambiguous "yes", and I have made changes to that
effect in my edits.  If the answer is meant to be "no", then I will
have to raise a formal objection, because that would IMHO mean that
DANE provided no improvements over the status quo.

Second, I have added constraints on client behavior based on DNSSEC
status alone.  This is arguably out of scope for this standard, but
I think the additions are necessary to preserve the security benefits
of DANE in the presence of active tampering with the DNS.

Third, I have added text about a potential non-security use of TLSA
records -- to enable TLS handshake optimizations -- and about user
override of TLSA-based rejection of a certificate.  These were not
addressed in the current draft, but I believe they add value.

I am speaking as a security researcher and as a Web browser
implementor.  I am not speaking on behalf of any other individual or
organization; however, I have received positive feedback on earlier
drafts of these edits from other browser implementors.

Thanks for your attention,
zw

---- proposal begins ----

Section 1.2: Delete the sentence "The DNSSEC signature MUST be
validated on all responses in order to assure the proof of origin of
the data" and the subsequent paragraph break.  (An equivalent, but
more specific, requirement will reappear in section 3.)

Section 1.3: Delete the entire second paragraph.

Section 2.2: Replace the paragraph that begins "Both types are
structured ..." with this text:

    Certificates of type 1 and 2 MUST be in PKIX format: that is, they
    must be structured according to the formatting rules in RFC 5280,
    and encoded using ASN.1 DER.  However, as described in section 3.4,
    type 1 certificates do not need to adhere to all the semantic
    rules in RFC 5280.  If it is desired to use other certificate
    formats with this specification in the future, those formats must
    be assigned their own certificate type numbers, and the definition
    of "associated" in section 3.1 of this specification must be revised
    appropriately.

Delete the paragraph that begins "Certificate types 1 and 2 explicitly
only apply ..." (having been folded into the above).

Section 2.3:  Delete all text before the beginning of section 2.3.1.
(Equivalent but clearer text will reappear in section 3.)

Section 2.3.1: Move contents to section 3.4 (marked below).

Section 3: Replace entire section with this text:

 3. Client application behavior in the presence of TLSA records

    The primary purpose of TLSA records is security.  However, TLSA
    information might also be useful for protocol optimizations that
    require advance knowledge of what the server's end-entity
    certificate should be.  Clients that use TLSA information only for
    such optimizations, and not for security decisions, are exempt
    from all other requirements in this section.

    Clients that make security decisions based on TLSA information
    MUST be, or have access to, security-aware DNS resolvers as
    defined by RFC 4033.  The rest of this section applies only to
    such clients, which will be referred to as "DANE clients".

 3.1. Definitions

    A certificate received in the TLS handshake is said to _match_ a
    TLSA record if:

    o  The TLSA record has reference type 0 and the certificate from
       the handshake is byte-for-byte identical to the certificate for
       association; or

    o  The TLSA record has some other reference type, and the hash of
       the certificate from the handshake (using the hash algorithm
       specified by the reference type) is byte-for-byte identical to
       the certificate for association.

    A certificate bundle received in the TLS handshake is said to be
    _associated_ with a domain name by DANE, if a TLSA record for the
    host, protocol, and port exists, the end-entity certificate in the
    bundle contains a name record that matches the host, and:

    o  The TLSA record has certificate type 1, and it matches the
       end-entity certificate in the bundle; or

    o  The TLSA record has certificate type 2, it matches one of the
       non-end-entity certificates in the bundle, and the end-entity
       certificate in the bundle has a valid chain to the certificate
       that matched the TLSA record.

 3.2. DNSSEC validation

    DANE clients MUST NOT proceed with a connection to a server if the
    DNSSEC validation status is "bogus" for _any_ DNS records relating
    to that server.

    DANE clients MUST ignore TLSA records whose DNSSEC validation
    status is "insecure" or "indeterminate" (however, such records MAY
    be used for TLS handshake optimizations as mentioned above).
    DANE clients MUST also ignore TLSA records whose certificate type
    or hash type they do not understand.

    A TLSA record whose DNSSEC status is "secure", and whose
    certificate and hash types are understood by the client processing
    it, will henceforth be referred to as a _trusted_ TLSA record.

 3.3. DANE validation

    The presence in the DNS of a trusted TLSA record is an assertion
    by the zone administrator that the legitimate server(s) for that
    host, protocol, and port will use certificate bundles that can be
    associated with the domain name by that record (as defined in
    section 3.1), and no others.

    Therefore, a DANE client in possession of a trusted TLSA record
    for a server MUST determine whether that TLSA record associates
    the server's domain name with the certificate bundle it provides
    in the TLS handshake.  If it does not, a DANE client MUST reject
    the end-entity certificate and abort the TLS handshake with an
    "access_denied" error.  This rule applies even if the end-entity
    certificate would have been trusted in the absence of the TLSA
    record.

    Conversely, if the TLSA record _does_ associate the server's
    certificate bundle with its domain name, a DANE client MUST treat
    the end-entity certificate as possessing a valid chain to a trust
    anchor, until the TTL of the TLSA record expires.  In other words,
    under these circumstances a DANE client MUST NOT reject a server's
    end-entity certificate solely for lack of a trust anchor.
    Furthermore, if the TLSA record providing the association has
    certificate type 1, a DANE client MUST NOT reject an end-entity
    certificate for violation of the PKIX rules that are relaxed by
    section 3.4 of this specification.

    However, if there is any _other_ reason why a server's end-entity
    certificate would have been rejected in the absence of TLSA
    information, a DANE client SHOULD still reject that certificate.
    For instance, if a certificate anywhere in the server's bundle has
    expired or has been revoked by its issuing CA, a DANE client
    SHOULD reject the end-entity certificate, even if the TLSA record
    matches a point in the chain before the invalid certificate.

    DANE associations provide a trust anchor _only_ for end-entity
    certificates, even if the TLSA record has certificate type 2.
    A DANE client MUST NOT allow any non-end-entity certificate in
    a certificate bundle that is anchored by a DANE association to
    become trusted for any domain name other than the one in the
    original association.

    DANE does not assure any information in a certificate other than
    the public key and its binding to host, protocol, and port.  Most
    importantly, DANE does _not_ assure any non-DNS name records.

 3.4. Relaxation of PKIX semantics for self-signed certificates

    (insert former contents of section 2.3.1 here)

 3.5. User override

    DANE clients SHOULD NOT allow their human users to force the
    establishment of a connection that has been aborted for any of the
    reasons listed in sections 3.2 or 3.3.

    A client that has good reason not to comply with this requirement,
    such as a forensic tool, SHOULD assume that the other end of a
    forced connection is actively malicious.  Therefore, the client
    SHOULD take precautions to avoid compromising the local computer
    or any of the user's data, such as:

    o  Not transmitting "cookies" or any other information that should be
       confidential to the legitimate server;
    o  Not executing any code (e.g. JavaScript) received over the
       connection;
    o  Not triggering further network traffic based on the normal
       semantics of the data received (e.g. images referenced by an
       HTML page) without explicit user instructions to do so.

---- proposal ends ----

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Mar 2011 21:34:12 +0200

{I think you should start three threads for your three proposals}

>>>>> "Zack" == Zack Weinberg <[email-masked]> writes:
    Zack> The exceptions are: First, it is not clear to me whether the present
    Zack> intent of the spec is that a TLSA record for site S specifying
    Zack> certificate X forbids a compliant client from proceeding with the
    Zack> handshake if it receives certificate Y.  I think the answer to this
    Zack> question must be an unambiguous "yes", and I have made changes
    Zack> to that effect in my edits.  If the answer is meant to be
    Zack> "no", then I will have to raise a formal objection, because
    Zack> that would IMHO mean that 
    Zack> DANE provided no improvements over the status quo.

I can't parse "yes"/"no" in the above sentence.
Do you mean:

  A TLSA record for site S specifying certificate X forbids a compliant
  client from proceeding with the handshake if it receives certificate Y. 

or do you mean to object to this statement?  I think you mean to support
it but I couldn't tell from the overview, and only from the text you supplied.

    Zack> o  The TLSA record has certificate type 1, and it matches the
    Zack> end-entity certificate in the bundle; or

    Zack> o  The TLSA record has certificate type 2, it matches one of the
    Zack> non-end-entity certificates in the bundle, and the end-entity
    Zack> certificate in the bundle has a valid chain to the certificate
    Zack> that matched the TLSA record.

...

    Zack> 3.3. DANE validation

    Zack> The presence in the DNS of a trusted TLSA record is an assertion
    Zack> by the zone administrator that the legitimate server(s) for that
    Zack> host, protocol, and port will use certificate bundles that can be
    Zack> associated with the domain name by that record (as defined in
    Zack> section 3.1), and no others.

    Zack> Therefore, a DANE client in possession of a trusted TLSA record
    Zack> for a server MUST determine whether that TLSA record associates
    Zack> the server's domain name with the certificate bundle it provides
    Zack> in the TLS handshake.  If it does not, a DANE client MUST reject
    Zack> the end-entity certificate and abort the TLS handshake with an
    Zack> "access_denied" error.  This rule applies even if the end-entity
    Zack> certificate would have been trusted in the absence of the TLSA
    Zack> record.

    Zack> Conversely, if the TLSA record _does_ associate the server's
    Zack> certificate bundle with its domain name, a DANE client MUST treat
    Zack> the end-entity certificate as possessing a valid chain to a trust
    Zack> anchor, until the TTL of the TLSA record expires.  In other words,
    Zack> under these circumstances a DANE client MUST NOT reject a server's
    Zack> end-entity certificate solely for lack of a trust anchor.
    Zack> Furthermore, if the TLSA record providing the association has
    Zack> certificate type 1, a DANE client MUST NOT reject an end-entity
    Zack> certificate for violation of the PKIX rules that are relaxed by
    Zack> section 3.4 of this specification.

    Zack> However, if there is any _other_ reason why a server's end-entity
    Zack> certificate would have been rejected in the absence of TLSA
    Zack> information, a DANE client SHOULD still reject that certificate.
    Zack> For instance, if a certificate anywhere in the server's bundle has
    Zack> expired or has been revoked by its issuing CA, a DANE client
    Zack> SHOULD reject the end-entity certificate, even if the TLSA record
    Zack> matches a point in the chain before the invalid certificate.

    Zack> DANE associations provide a trust anchor _only_ for end-entity
    Zack> certificates, even if the TLSA record has certificate type 2.
    Zack> A DANE client MUST NOT allow any non-end-entity certificate in
    Zack> a certificate bundle that is anchored by a DANE association to
    Zack> become trusted for any domain name other than the one in the
    Zack> original association.

    Zack> DANE does not assure any information in a certificate other than
    Zack> the public key and its binding to host, protocol, and port.  Most
    Zack> importantly, DANE does _not_ assure any non-DNS name records.

I like your text.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Zack Weinberg <[email-masked]>
Date: Mon, 28 Mar 2011 14:01:26 -0700

> {I think you should start three threads for your three proposals}

It is one proposal.  I could split out the additional text about
non-security use, but apart from that, it doesn't make sense to try to
break up the changes.

>    Zack> certificate would have been trusted in the absence of the TLSA

If it's not, please let me know how I could improve it.

zw

---

From: Jay Daley <[email-masked]>
Date: Tue, 29 Mar 2011 13:39:52 +1300

> If it's not, please let me know how I could improve it.

Two questions:

1.  How is the current text in 3. not good enough?

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

2.  Assuming there is a problem with that text and your replacement text is needed, then shouldn't this be more explicit about multiple TLSA records? (And also use correct terminology)

"A DANE client must determine whether the certificate bundle provided in the TLS handshake from a server found at a domain name matches a trusted TLSA record for that domain name.  If it does not ..."

Jay

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

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

---

From: Zack Weinberg <[email-masked]>
Date: Mon, 28 Mar 2011 18:02:30 -0700

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

Only in being more confusing than I would like.  I think it's vital to
be crystal clear how a client should behave in all cases.

By highlighting this text you reassure me that my changes to emphasize
the exclusivity properties of TLSA really are editorial, though, so
that's a relief.

> "A DANE client must determine whether the certificate bundle provided in the TLS handshake from a server found at a domain name matches a trusted TLSA record for that domain name.  If it does not .…

I changed the terminology (see text above this), again, to reduce
confusion.  An entire certificate bundle does not match anything
anymore, it can only be associated.  Only single certificates match.

You're right, though, I forgot to consider the case of multiple TLSA
records.  I'll need to tweak wording throughout to fix that, I think.

zw

---

From: Jay Daley <[email-masked]>
Date: Tue, 29 Mar 2011 14:27:57 +1300

> be crystal clear how a client should behave in all cases.

Sorry to be a pain, but I struggle to see how this is confusing.  Can you explain?

> the exclusivity properties of TLSA really are editorial, though, so

Good.

> I changed the terminology (see text above this),

I'm not sure what you are referring to.  Did I miss some text?

Jay

> again, to reduce

---

From: Paul Wouters <[email-masked]>
Date: Tue, 29 Mar 2011 04:34:49 -0400 (EDT)

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

I am assuming we will see deployment of DANE and PKIX alongside,
where there might be contradictions or discrepancies between these two
(or even other methods of obtaining this information out of band). I
think what should be stated is that the "DANE validation path" should
be aborted. We should not dictate to abort the TLS handshake. It would
be up to a client/browser to implement one or more trust anchor methods
(PKIX, DANE, LDAP, caching) and decide to abort the TLS handhshake only
after all its trusted methods have failed.

Paul

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 29 Mar 2011 10:43:11 +0200

I actually really disagree with the idea that DANE would be some parallel, alternative path to PKIX validation.  If DANE is going to be meaningful, it needs to be able to cause the TLS handshake to fail -- this is the correct behavior when the server says (through DANE) that things should be one way and they aren't.

The relationship between DANE and PKIX is one of the topics for discussion at the DANE meeting tomorrow.  As I'll present (in a discussion too long for this email), they can actually work together very naturally.

--Richard

---

From: Paul Wouters <[email-masked]>
Date: Tue, 29 Mar 2011 05:24:09 -0400 (EDT)

> DANE provided no improvements over the status quo.

I think the client should decide which trust models (DANE, PKIX, others)
it intends to trust. I do not think these trust models should make
statements about the other models. The original section 3 starts out
with doing this ("MUST be marked as unusable." [Paul: by DANE])
correctly, but then later on assumes DANE trumps everything ("MUST abort
the handshake ")

> of DANE in the presence of active tampering with the DNS.

DNSSEC should be a requirement for DANE. I thought this was already in
the 06 draft? Ah, it is in Section 3.

> more specific, requirement will reappear in section 3.)

I think it would be good to state the relationship between DNSSEC and TLSA
at the beginning of the draft. I agree that this sentence is not the best,
because it kind of implies the client has to do the validation itself from
the root down, and not trust the AD bit on responses received from its
(secure) connection to a validating name server, which I think is not what
the authors intended. Though it is clarified in the orignal section 3.

> Section 1.3: Delete the entire second paragraph.

Agreed. My reasoning being that DANE should not exlucde PKIX (just like PKIX
should not be allowed to exclude DANE). This should be a client choice.
See above on the contraction in the original section 3.

>    rules in RFC 5280.

This sounds okay.

>     If it is desired to use other certificate

I am not sure if this is required after the previous paragraph.

Note also that in the future, there will be other type of TLSA records not
involving PKIX certificates, such as those containing just bare public keys.
Ideally, I would like to see a different name for "certificate type" and
call it "identifier type" or something. Then part of this text should move
to the section describing the type 1 and type 2 identifiers specifically.

>    from all other requirements in this section.

I assume you are trying to say that client/servers supporting this could
skip the exchange of PKIX information in the TLS handshake. In fact, that
is pretty much what my draft for "TLS Extensions for out of bound public
key validation" adds an option for. However, the above paragraph stating
something like "you can use this info but not treat it as secure" makes me
very nervous. I would be uncomfortable introducing a concept of "insecurely
obtaining TLS public keys from DNS". My TLS extension draft addresses this
by saying the TLS client could have cached the TLS public key from a previous
handshake or have obtained this via another secure(!) method like DANE or LDAP.

>    such clients, which will be referred to as "DANE clients".

This is a DANE document, you cannot really say in the above paragraph that
such a client using insecure TLSA from DNSSEC is not a "DANE client". Clients
using this draft/rfc are "DANE clients".

>       the certificate for association.

With my proposed TLS extension, the whole PKIX transmission could be
suppressed, but this paragraph assumes it is always sent. I also get
nervous about terms lie "byte for byte" since we have things like network
ordered bytes.

>    bundle contains a name record that matches the host, and:

I see more people using wildcard certs (*.xelerance.com) which would not
match "a name record"....

>    DNSSEC validation status is "bogus" for _any_ DNS records relating

Don't say "connection". Say that the "DANE trust path" must be aborted. The
client might still do PKIX or other methods. The DANE specification should
not forbid those so it should not dictate to close the connection.

>    be used for TLS handshake optimizations as mentioned above).

See above. I still don't understand this "insecure use" of TLSA. Either you
obtained it securely outside of DANE to use, in which case DANE does not apply,
or you only got it via DANE, in which case you should not use it if it was not
secured. One DoS attack I could imagine here is spoofing bogus DANE records and
the client trying to "optimise" to the server and botching the TLS handshake
repeatedly.

>    it, will henceforth be referred to as a _trusted_ TLSA record.

Again, I don't agree with a "untrusted TLSA record" concept.

>    section 3.1), and no others.

I think we definitely need to discuss the "no others" part. I can see
its use to ignore any bogus PKIX issued certificates, but I don't think
this should be a zone administrator decision. It should probably be a client
decision to disable PKIX or disable PKIX in the precense of DANE records.

>    information, a DANE client SHOULD still reject that certificate.

This is the fundamental problem of storing things like "Validity"
of the PKIX into a DNS record with a validatity based on TTL/RRSIG
lifetimes. This is also why I am writing the DANE public key draft, which
has as one of its goals not to add possibly contradicting information
from PKIX into DNS.

I would say if you store full PKIX into DNS then you should ensure that
both the DNS and the PKIX information is valid, and reject it if either
one fails. Especially if a method is available where you can store the
bare public key in DNS and avoid all these conflicts.

One of the advantages of DANE is you can put your public key in DNS and
forget about things like re-signing your certificate and expiration.

>    matches a point in the chain before the invalid certificate.

Should it? I am not sure I agree (or disagree)
If we have a bare public key option, then I can agree with this, as
anyone who cares can then pub just the pubkey in DNS and then for
compat reasons (or other) keep a valid PKIX on the server as well.

>    become trusted for any domain name other than the one in the

This might get complicated with wildcards, both in DNS as well as in
the CN= or SubjectAltname=

>    the public key and its binding to host, protocol, and port.

This is a real problem, as clients would have to store the certificate
in their certificate pool, yet mark it was obtained by DANE and/or what
parts were validated. I was told by at least one major browser vendor
that this is a serious problem. I would say that if the entire cert
was in DANE, then DANE assures ALL the information in that certificate.
After all, the RRSIG was over the entire certificate.

And again, this assumes the alternative of bare public keys in DANE
exist for those who only want to assure the port/transport/name and
public key.

>  Most importantly, DANE does _not_ assure any non-DNS name records.

How is an implementation supposed to keep track? I would strongly suggest
people who desire this should use bare public keys in DANE instead.

>    reasons listed in sections 3.2 or 3.3.

That's not up to the network protocol to decide. Leave that up to the
application developers to deal with. Even if you state it here, it will
get ignored. But I don't think the protocol should tell me how much I
should trust it. Just like I want to decide how much to trust (or not)
PKIX, I will decide how much to trust DANE. That not every enduser can
make an informative decision is something the application people are
much better suited to address properly then network protocol engineers.

Paul

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 29 Mar 2011 08:09:15 -0700

> I actually really disagree with the idea that DANE would be some parallel, alternative path to PKIX validation.  If DANE is going to be meaningful, it needs to be able to cause the TLS handshake to…

I concur with this.  I see this as possibly *the* security benefit
relative to the status quo.

zw

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 29 Mar 2011 16:09:07 -0700

> correctly, but then later on assumes DANE trumps everything ("MUST abort

We disagree so profoundly that I can only conclude you have an
entirely different notion of what DANE is good for than I do.

Here's how I see it: The gating audience for DANE is site admins, who
must be persuaded that adding TLSA records (and DNSSEC signatures) to
their zones is a valuable thing for them to do.  Site admins are not
going to go for this pitch:  "If you put TLSA records in your zone and
sign it, then DANE-compliant clients will do something with that
information.  We can't tell you what, because we thought that policy
should be up to the client.  Some of your users might get some sort of
security benefit out of it.  Others might find themselves unable to
use your site."

They are much more likely to go for this pitch: "If you put TLSA
records in your zone and sign it, then all DANE-compliant clients will
react to those records in this predictable fashion: [....] This
protects those users from these actual security threats: [....]
However, if your site is ever misconfigured in this specific way:
[...] then it will become inaccessible to DANE-compliant clients, so
you need to make sure that your operational procedures never let that
happen."

Therefore, I do not think the client should decide who to trust.  I
think DANE needs to decide and specify that decision with as little
wiggle room as possible, and I think it *especially* needs to specify
what to do when DANE disagrees with other trust models (PKIX being the
only such at present).  And that's what I've tried to do with my
revisions.

> the 06 draft? Ah, it is in Section 3.

The new requirement I added is "MUST NOT proceed with a connection to
a server if the DNSSEC validation status is 'bogus' for _any_ DNS
records relating to that server".  The old language could be read to
say that TLSA records should be _ignored_ when DNSSEC validation came
back "bogus", and did not state anything about what should happen if
the TLSA record was properly signed but the A record was bogus.

With my wording, the only way an attacker with the power to tamper
with DNS responses can downgrade a client to backward-compatible
PKIX-only mode (for a server that does provide signed TLSA records) is
by suppressing _all_ DNSSEC information.  I think this is a valuable
property.

> the authors intended. Though it is clarified in the orignal section 3.

The main reason I proposed modifications to sections 1 and 2 is to
_consolidate_ all requirements upon the client in section 3, for
clarity's sake.  I'd be okay with leaving an informative sentence
early in the document along the lines of "TLSA records are only useful
for security when the DNS zone they appear in is protected from
tampering by DNSSEC signatures", but I want that to be redundant to
normative, MUST-requirement text in section 3.

...
> I am not sure if this is required after the previous paragraph.

I wouldn't especially miss it, but equivalent language was in the -06
draft and I didn't see any harm in preserving it.

> to the section describing the type 1 and type 2 identifiers specifically.

I would support that change.  However, I feel it is off-topic for this
change proposal, which I would prefer to keep focused on nailing down
client behavior.

> skip the exchange of PKIX information in the TLS handshake.

Sort of.  I was specifically thinking of snap start [
http://tools.ietf.org/html/draft-agl-tls-snapstart-00 ] when I wrote
that paragraph - that perhaps having the end-entity certificate
out-of-band would allow a client to do snap start on the first
connection to a previously unknown server.  Having reread the snap
start spec, it looks like that won't work (the client needs to know
several other things) and even if it did, it would be a bad idea to do
it on insecure/indeterminate data.  And it's off topic anyway.  I will
drop this part of the proposal.

> using this draft/rfc are "DANE clients".

Dropping the optimization-only text would render this moot, I think?
I could just say "Clients MUST themselves be, or have secure access
to, security-aware DNS resolvers" and scrap the "DANE client" wording
below.

> suppressed, but this paragraph assumes it is always sent.

Do you have a link to your proposal?  I'm happy to adjust the wording
appropriately - the intent is just to be clear about what exactly is
being "matched".

> I also get

Fair point, but the comparison function needs to be specified
precisely - "identical" is not precise in my book - and pace Peter
Gutmann's complaints about "memcmp() is the only way to compare PKIX
certificates", I don't know a better option than "byte-for-byte".
Maybe the thing to do is nail down the byte order of the certificate
for association in section 2.

> match "a name record"....

I'm open to suggestions for better wording here.  I don't have a lot
of experience with DNS wildcards _or_ certificate wildcards.

> not forbid those so it should not dictate to close the connection.

On the contrary.  If DANE can't dictate a connection abort it is
useless, and if DANE allows a client to proceed with a connection when
DNSSEC signature checks have come back "bogus", a DNS-tampering
attacker can subvert it.

The DANE specification _absolutely must_ dictate a connection abort
under these circumstances.  If equivalent wording is not in the final
draft I will raise a formal objection (or whatever the appropriate
term is, sorry, I know W3C procedure a lot better than IETF
procedure).

> See above. I still don't understand this "insecure use" of TLSA.

Will drop the parenthetical.  Do you agree that ignoring the record is
the Right Thing when DNSSEC validation comes back insecure or
indeterminate?

> Again, I don't agree with a "untrusted TLSA record" concept.

This is just meant to make it unambiguous, below, that records that
were ignored for lack of a zone signature, or because the client
doesn't understand the type codes, do not count.  Maybe I should
replace "trusted" with "usable"?

> decision to disable PKIX or disable PKIX in the precense of DANE records.

It has to be a zone administrator decision, so that the zone
administrator knows the consequences of adding TLSA records to their
zone (see discussion way up top).  Leaving this as an application
decision will only ensure that nobody uses DANE.

...
> one fails.

That was in fact the intent of my text.  How was it unclear?

> Especially if a method is available where you can store the

I'm good with a bare-public-key option but I will not make this
proposal depend on the addition of a bare-public-key option.  The WG
has been arguing over bare public keys for weeks now, and I've got
plenty of potential for controversy in here already, thanks.

> the CN= or SubjectAltname=

The intent is to trust only the end-entity cert and only for the
domain name that was *queried*.  Please suggest wording improvements.

> After all, the RRSIG was over the entire certificate.

What I'm really going after here is the DV/EV distinction; I want to
specify that DANE does _not_ provide EV.  However, EV is a marketing
term rather than a technical term, so it doesn't belong in a spec like
this.  The _effect_ of EV is, if a certificate is signed by a
particular CA certificate, then more of the name fields are considered
trustworthy.  So by saying "does not assure any information other than
..." I was trying to specify a similar effect (or rather, the absence
of a similar effect). Again, I'm open to wording improvements.

> That's not up to the network protocol to decide.

That's why it's a SHOULD rather than a MUST (and why there is a
specific example of an application that might ignore the
recommendation).  But I think it's important to have this advice to
applications in the spec, again, so that the behavior of clients is
predictable - in this case, so that site admins can assume fail-hard
behavior.

> Even if you state it here, it will get ignored.

I will be making efforts to ensure it doesn't for HTTPS (by working
with browser vendors).

zw

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 29 Mar 2011 16:23:52 -0700

> Sorry to be a pain, but I struggle to see how this is confusing.  Can you explain?

Had to think about it for a while, but my big problem with it is the
"match between one of the certificate associations and the end entity
certificate" language.   An _association_ is a weird thing to _match_.

There is also a jumble of MUST-language and non-MUST language in here
("the TLS client continues" versus "the TLS client MUST abort".

> I'm not sure what you are referring to.  Did I miss some text?

The "definitions" section in my proposal.  The way you'd say this in
my language is

   ... must determine whether the server's certificate bundle ... can
be associated with the
   server's domain name by at least one of the TLSA records for that
domain name ...

Note how the TLSA record is not itself an "association", it's just a
"record", whose effect is to _match_ one of the certificates in the
in-band bundle, and thus form an association between the bundle and
the _name_.

In my next draft, having taken on board some of Paul Wouters'
comments, I think I'll say that the association is between the
_server_ and the name.

zw

---

From: Paul Wouters <[email-masked]>
Date: Wed, 30 Mar 2011 02:54:01 -0400 (EDT)

On Tue, 29 Mar 2011, Zack Weinberg wrote:

[more later after the WG meeting]

> Do you have a link to your proposal?  

ftp://ftp.xelerance.com/tls-oob/

Note that I have not finished it yet. Please consider it a pre-release

Paul