Subject: [dane] Scope of the protocol document or plea for progress

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 16 Nov 2011 06:33:46 +0800

Dear colleagues,

I'm getting worried that the WG is falling off the tracks, it is
getting distracted by trying to address every possible corner case.

I want to propose that the Current protocol document explicitly only 
cover the following case:
     Target zone is DNSSEC signed [1]
and    Consumer performs DNSSEC validation [2]
and     Target zone can be validated by the consumer.

In this case there are two positive outcomes:
     - Validated TLSA RRset
     - Proof that the TLSA RRset does not exist

and one Negative outcome:
     - TLSA RRset fails validation

The document should say what the Consumer application does in each one 
of these cases for each type TLSA of record  i.e. if there is need to 
check revocation lists, etc.

For the other cases we just say "The consumer application falls back to 
the processing it is currently doing".

This is the 98% solution and the faster we can start deploying it the 
better off we are!!!!

A subsequent document can address the transition cases i.e. when
DNSSEC validation can not succeed due to:
     Breaks in trust chain
     Algorithm mismatch
     Unsigned publisher zone
     No Validating resolver available
     DNSSEC records not getting through
     timeouts
     Incomplete Trust Chain
     etc.

I would call this document
"Value of TLSA records when DNSSEC validation is not available".

I feel that using words like "DNS optional" does nothing but confuse 
both potential publishers and consumers of TLSA records as well as the 
implementors.

I want to thank Richard Barnes for forcing me to think though the 
implications of his incomplete flow chart on the document. [3]
My subsequent flowchart takes multiple pages and is not yet complete, 
thus I think any document that tries to address those issues will take a 
long time to write. Conversely writing such a document will be
much easier if the positive cases are taken out of it.

     Comments
     Olafur

[1] Target zone is the zone the name of the service resides in, i.e.
     the name _443._tcp.gmail.com is in gmail.com or _tcp.gmail.com.

[2] Consumer has a DNSSEC capable validator that she/he trusts the 
answer from.

[3] http://tools.ietf.org/agenda/82/slides/dane-2.pdf slide 9.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 15 Nov 2011 20:52:06 -0500 (EST)

On Wed, 16 Nov 2011, Olafur Gudmundsson wrote:

> I want to propose that the Current protocol document explicitly only cover 
> the following case:
> The document should say what the Consumer application does in each one of 
> these cases for each type TLSA of record  i.e. if there is need to check 
> revocation lists, etc.
>
> For the other cases we just say "The consumer application falls back to the 
> processing it is currently doing".

Fully agree!

Paul

---

From: Antoin Verschuren <[email-masked]>
Date: Wed, 16 Nov 2011 02:19:29 +0000

+1

-- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]
http://www.sidn.nl/

On 16-11-11 02:52, "Paul Wouters" <[email-masked]> wrote:

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

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Nov 2011 04:37:17 +0200

+1

Yoav

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 16 Nov 2011 13:03:56 +0800

+1

Eric

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 15 Nov 2011 21:05:14 -0800

>>>> getting distracted by trying to address every possible corner case.

Yet Another +1

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 16 Nov 2011 13:21:49 +0800

I very much like the idea of having KISS solution in the DANE protocol document
and if there's interest (and a volunteer) we can have another I-D covering
the corner cases.

Thanks to Olafur for pointing that we could have this in two step process.

With my chair hat on - could we get an consensus on:

> I want to propose that the Current protocol document explicitly only cover the following case:

I already saw several +1's on the list and I would like to see more
especially from the people who participated in the Taipei WG discussion
on this topic.

And here's +1 from me.

O.

On 16. 11. 2011, at 6:33, Olafur Gudmundsson wrote:

> I want to propose that the Current protocol document explicitly only cover the following case:
> The document should say what the Consumer application does in each one of these cases for each type TLSA of record  i.e. if there is need to check revocation lists, etc.
> 
> For the other cases we just say "The consumer application falls back to the processing it is currently doing".
> 
> This is the 98% solution and the faster we can start deploying it the better off we are!!!!
> 
> I feel that using words like "DNS optional" does nothing but confuse both potential publishers and consumers of TLSA records as well as the implementors.
> 
> I want to thank Richard Barnes for forcing me to think though the implications of his incomplete flow chart on the document. [3]
> My subsequent flowchart takes multiple pages and is not yet complete, thus I think any document that tries to address those issues will take a long time to write. Conversely writing such a document will be
> [2] Consumer has a DNSSEC capable validator that she/he trusts the answer from.
> 

--
 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: Miek Gieben <[email-masked]>
Date: Wed, 16 Nov 2011 07:32:26 +0100

[ Quoting <[email-masked]> at 06:33 on Nov 16 in "[dane] Scope of the ..." ]

+1

grtz Miek

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 16 Nov 2011 04:49:34 -0200

> and     Target zone can be validated by the consumer.

Fully agree,

Fred

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 16 Nov 2011 08:53:24 +0100

Thank you Olafur, I agree fully -  (and it would make my life as document (co)author a lot easier.

	jakob

---

From: Zack Weinberg <[email-masked]>
Date: Wed, 16 Nov 2011 08:16:15 -0800

I agree in principle with limiting scope creep - but I don't see that
there is scope creep here.

>   DNSSEC records not getting through

If DNSSEC validation state is "bogus", fail association.
If DNSSEC validation state is "insecure" or "indeterminate", ignore
all TLSA records.

That should be all that is needed.

zw

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Nov 2011 21:47:58 +0100 (MET)

Paul Wouters wrote:
> 
> Olafur Gudmundsson wrote:
> >

+1

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 17 Nov 2011 07:01:47 +0800

> That should be all that is needed.

I spoke with Olafur last night, and what you state here is not exactly what he intended. I'll let him say precisely what he intended so that people who already +1'd can decide if they still feel that way.

--Paul Hoffman

---

From: Brian Dickson <[email-masked]>
Date: Wed, 16 Nov 2011 18:12:04 -0500

+1

(+1,000,000 actually).

Brian

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 17 Nov 2011 09:04:43 +0800

> I spoke with Olafur last night, and what you state here is not exactly what he intended. I'll let him say precisely what he intended so that people who already +1'd can decide if they still feel th…
Yesterday Paul and I talked about this at length,
the DNSSEC-only document might/should give guidance on use policy in
the cases DNSSEC validation can not succeed.

There are two possible actions:
	Discard TLSA
	Specify use policy by TLSA sub-type

My intention was that the application make that choice but
explicitly state for each TLSA sub-type what the default policy for
that sub-type is:
	For sub-types 0 and 1 reuse is possible.
	For sub-type 2 "MUST ignore" is the only sane policy

For future sub-types the defining document MUST specify reuse policy.
(For bare keys the MUST ignore is also the only sane policy)

Thus I amend yesterdays proposal to explicitly put in scope of the 
document to specify the usage policy for each sub-type when DNSSEC does 
not succeed.
	
Having said this I realize TLSA is potentially headed for the sub-typing 
hell that TXT and NAPTR records suffer from.
The WG should have a short discussion about the design choice of
	"if single RR type or multiple RR types"
is a better way forward and the document should have the
justification for the choice made.

	Olafur

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Nov 2011 02:23:55 +0100 (MET)

> 	For sub-type 2 "MUST ignore" is the only sane policy

I strongly dislike *ANY* reuse.

As described in earlier discussions, for attackers that are
sufficiently close to the victim client to see his DNS requests
outgoing, it is trivial to reliably DNS spoof the client.

MITMing the clients TLS connections to the server is MUCH harder
(unless you happen to be the router on the path or coerce
 the client to believe that you're the router, an IPv6 feature).

By inserting fake DNS TLSA records, you can make the TLS client
that believe in TLSA absent of DNSSEC protection, reliably fail
connection to the real server that the attacker fails to MITM,
and showing only the connections that the attacker succeeds
to MITM as "trustworthy".  This is the "firesheep" scenario.

I strongly dislike the idea to have the client make flawed assumptions
that can backfire so badly.  Instead, I would really prefer to leave
the pressure on to create a TLS extension and convey the necessary
DNSSEC records inband with the TLS handshake.

-Martin

---

From: Zack Weinberg <[email-masked]>
Date: Wed, 16 Nov 2011 17:34:43 -0800

> the cases DNSSEC validation can not succeed.

Please avoid the term "can not succeed", as it might mean any of the 
three DNSSEC validation states "bogus", "insecure", or "indeterminate", 
and they have _very different_ security implications.

> Specify use policy by TLSA sub-type

Also "fail association" = "do not proceed with TLS handshake".

> My intention was that the application make that choice

I think this would be a mistake.

 > but

I also think it would be a mistake to have the behavior vary based on 
subtype.

> hell that TXT and NAPTR records suffer from.

Quite so.

zw

---

From: Richard Barnes <[email-masked]>
Date: Thu, 17 Nov 2011 09:45:46 +0800

Hey Olafur,

I think you're re-creating the rathole you were trying to avoid.  I would be satisfied for this document to define a process that terminates in the same "NO-INFO" state whether there are no records or insecure records.  Re-use recommendations can be addressed in a separate document.

--Richard

On Nov 17, 2011, at 9:04 AM, Olafur Gudmundsson wrote:

> Thus I amend yesterdays proposal to explicitly put in scope of the document to specify the usage policy for each sub-type when DNSSEC does not succeed.
> 	
> Having said this I realize TLSA is potentially headed for the sub-typing hell that TXT and NAPTR records suffer from.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 17 Nov 2011 09:47:43 +0800

+1

I've sketched out a client decision process in state table and ASCII art form below.  The process takes a name and a certificate chain, and has three outcomes: 

GOOD - DANE indicates that you should accept this certificate chain for this name
BAD - DANE indicates that you should not accept 
NO-INFO - DANE provides no information about whether you should accept

That is, the NO-INFO case is as if there were no DANE records at all (with secure nonexistence, natch).

--Richard

-----BEGIN ASCII ART-----

      +-------------+ 
      | name, chain |
      +-------------+ 
             |
             v
/---------------------------\
| IN TLSA _port._proto.name |
|  with DNSSEC validation   |
\------------+--------------/
             |
             v
        +---------+        **********
        |  bogus? |---Y--->*  BAD   *<------------+
        +----+----+        **********             |
             |                                    |
             N                                    N
             |                                    |
             v                                    |
        +---------+        +---------+        +--------+
        | secure? |---Y--->| exists? |---Y--->| match? | 
        +---------+        +---------+        +--------+
             |                  |                 |
             N                  N                 Y
             |                  |                 |
             v                  |                 |
        ***********             |             **********
        * NO-INFO *<------------+             *  GOOD  *
        ***********                           **********

-----END ASCII ART-----

-----BEGIN STATE TABLE-----
DNSSEC      Exists  Matches     Outcome
=======================================
bogus       *       *           BAD
secure      yes     no          BAD
secure      yes     yes         GOOD
secure      no      *           NO-INFO
other       *       *           NO-INFO

---

From: Yoav Nir <[email-masked]>
Date: Thu, 17 Nov 2011 03:49:08 +0200

> 	For sub-type 2 "MUST ignore" is the only sane policy

I agree with Martin and Zack. A signature that doesn't validate (whether "insecure" or "indeterminate") is like no signature at all, and should be treated the same.

Just require DNSSEC.

Yoav

---

From: Scott Schmit <[email-masked]>
Date: Wed, 16 Nov 2011 20:57:42 -0500

> (For bare keys the MUST ignore is also the only sane policy)

I'm sorry, it's been a long day, so maybe I'm missing the obvious, but
what do you mean by "reuse policy"? Reuse of what?

-- 
Scott Schmit

---

From: Zack Weinberg <[email-masked]>
Date: Wed, 16 Nov 2011 17:59:04 -0800

> NO-INFO - DANE provides no information about whether you should accept

This I can support, and the flowchart looks right to me.

I would add one additional thing: go to state BAD if the *address
record* lookup comes back "bogus", and to NO-INFO if that came back
non-"secure".  (I can't immediately think of a scenario where forging
A(AAA) but not TLSA leads to anything worse than denial of service,
since if the attacker can produce a cert chain that matches the
legitimate TLSA records you've already lost; but I'm not certain there
isn't one and extra defensiveness can't hurt.)

zw

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 17 Nov 2011 10:14:25 +0800

> I agree with Martin and Zack. A signature that doesn't validate (whether "insecure" or "indeterminate") is like no signature at all, and should be treated the same.

Define "the same": you can use the data you got if you want, or act as if you didn't the data. Extra points for saying if it is true for all three types.

> Just require DNSSEC.

OK, but what does that mean if DNSSEC is required and the data comes as "indeterminate"?

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Nov 2011 21:19:41 -0500 (EST)

On Thu, 17 Nov 2011, Olafur Gudmundsson wrote:

> Thus I amend yesterdays proposal to explicitly put in scope of the document 
> to specify the usage policy for each sub-type when DNSSEC does not succeed.

I think the WG name and charter says it all:

DNS-based Authentication of Named Entities

   Specify mechanisms and techniques that allow Internet applications to
   establish cryptographically secured communications by using information
   distributed through DNSSEC for discovering and authenticating public
   keys which are associated with a service located at a domain name.

It was no accident that it did not talk about non-DNSSEC and/or
non-authenticated DNS records.

> justification for the choice made.

That's because some people want to stuff the whole OID PKIX tree in there.

I think sub types for CA, EE and pubkey are reasonable. I have no idea
what other identifiers one could want that do not fall within one of these
three types.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Thu, 17 Nov 2011 04:23:28 +0200

> Define "the same": you can use the data you got if you want, or act as if you didn't the data. Extra points for saying if it is true for all three types.

Revert to the behavior the client would have if there had been no TLSA record at all. Yes, do it for all types.

> OK, but what does that mean if DNSSEC is required and the data comes as "indeterminate"?

Ignore the TLSA record. Client falls back to the same behavior it would have if no TLSA record had ever been received.

And that probably means revert to PKIX. And yes, in case #2 that means either fail association, or the way browsers do it today - with a big red warning screen.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Nov 2011 21:26:18 -0500 (EST)

> OK, but what does that mean if DNSSEC is required and the data comes as "indeterminate"?

I'm not sure I understand the "indeterminate" state. You either got the TLSA record with
proper DNSSEC validation, or you got the proof it does not exist, or you got a bogus answer,
or you got a TLSA record which provably has no protection.

In the first case you proceed only if the TLSA matches the TLS Server cert.
In the second case you proceed without the use of TLSA.
In the third case you reject the TLSA record and either abort or continue without TLSA
depending on local policy.
In the fourth case you ignore the TLSA record as if it did not exist (as you don't want
someone spoofing it causing you to abort connecting and attempt other auth schemes like PKIX)

Am I missing something?

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 17 Nov 2011 10:34:56 +0800

On Nov 17, 2011, at 10:26 AM, Paul Wouters wrote:

> I'm not sure I understand the "indeterminate" state.

RFC 4033:
   Indeterminate: There is no trust anchor that would indicate that a
      specific portion of the tree is secure.  This is the default
      operation mode.

> You either got the TLSA record with

According to the standard we are talking about, it is the latter.

> someone spoofing it causing you to abort connecting and attempt other auth schemes like PKIX)

That is a reasonable choice, and not the only one.

> Am I missing something?

Maybe that there might be people with different opinions?

--Paul Hoffman

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 17 Nov 2011 06:08:06 +0000

Op 17 nov. 2011, om 02:04 heeft Olafur Gudmundsson het volgende geschreven:

This is the only sane thing for the DANE protocol to define.
If you do DANE, the TLSA record needs to be validated. If it cannot be validated, do NOT use the record.

This is not for DANE to decide. Do it in another working group.
If the record is not validated, you're not doing DANE.

If you want to use the cert or any other content of the rrdata for any other process to try to get a secure connection, fine, but you're not doing DANE. I would suggest to put the content of the cert in a CERT RR and try to do your verification trick over there depending on sub-type. How to do that might be in a different document, possibly owned  by the PKIX WG, or as an individual submission, but it certainly is NOT DANE.

I don't think DANE needs to inherit all flaws in other protocols, not the flaws in DNSSEC nor the flaws in PKIX, they are up to a different WG defining that protocol. DANE is not here to fix the whole world, or we will never finnish DANE.

Antoin.

---

From: Peter Koch <[email-masked]>
Date: Thu, 17 Nov 2011 07:17:29 +0100

> justification for the choice made.

this concern can and probably should be addressed by a stricter policy
for the "Certificate Usages for TLSA Resource Records" registry.
However, in contrast to NAPTR, the use cases are not predetermined by
the client (as in DDDS/NAPTR), but definitely part of the response.

-Peter

---

From: Peter Koch <[email-masked]>
Date: Thu, 17 Nov 2011 07:35:36 +0100

> DNSSEC      Exists  Matches     Outcome

under the assumption that 'Exists' is to distinguish between
positive and negative (NXDOMAIN, NOERROR/NODATA {even though
unlikely}) DNS responses, the table mixes DNSSEC status
and content to make a decision which i'd consider a bit premature.

To stress a famous quote: DNSSEC is expensive error detection.
What to do in the absence of the AD bit is basically a local
decision.  In the case of DANE this decision probably has
different risks depending on the use case.

-Peter

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 17 Nov 2011 16:00:25 +0800

> and content to make a decision which i'd consider a bit premature.

I don't see this mix as something bad - you have DNSSEC statuses
in rows and DNS response + DANE match in columns.

> different risks depending on the use case.

And I think we are trying to avoid the "depending on the use case"
part for DANE protocol document, because:

a) it's getting complicated and we seem to be going in the circles
b) we can address that in separate document updating DANE protocol

O.

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 17 Nov 2011 09:31:07 +0100

> to MITM as "trustworthy".  This is the "firesheep" scenario.

A client received an insecure non-matching TLSA record knows for sure that something is fishy - either someone is doing bad things with their DNS, or someone is doing an MITM attack on TLS. I fail to see any disadvantage aborting such a TLS connection (or alert the user), as it may protect you from a subset of attacks (e.g., fraudulently issues certificates from a CA that the TLS server do not want to be associated with).

N.B.: this is the insecure non-matching case ONLY in combination with certificate usage type 0 and 1 ONLY.

	jakob

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Nov 2011 21:52:29 +0100 (MET)

Jakob Schlyter wrote:
> Martin Rex wrote:
> N.B.: this is the insecure non-matching case ONLY in combination
> with certificate usage type 0 and 1 ONLY.

Yes, of course.  AFAIK, noone suggested to believe in usage type 2
TLSA records where DNSSEC validation fails.

But think about what cert usage type 0 and 1 really means:

It means that someone managed to obtain a cert for which the
PKIX validation performed by the client will pass!

There is no point in DANE trying to protect from attacker who
can not do this, because the PKIX validation would reliably fail.

The purpose of using DANE  with usage types 0 and 1 at all is
giving the Domain Owner(!!) the ability to repudiate a certificate
that will pass the client's PKIX validation and server endpoint
identification.

Believing in non-DNSSEC TLSA records of types 0 and 1 will result
in exactly the opposite to be achievable for an attacker:

a) make a correct PKIX-validating and Domain-Owner approved TLS server cert
   look fishy by a simple DNS spoof and have clients abort.

and simultaneously

b) make a fraudulent but PKIX-validating and *NOT* Domain-Owner approved
   TLS server cert look acceptable by a simple DNS spoof and give clients a
   false sense of security.

-Martin

---

From: Tony Finch <[email-masked]>
Date: Thu, 17 Nov 2011 21:07:47 +0000

Zack Weinberg <[email-masked]> wrote:
> non-"secure".

I don't think there is any harm in having a secure TLSA record but
insecure address records, since TLS certificate validation will check
that you ended up connecting to the right place.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall: South or southeast 4 or 5, increasing 6 at times. Moderate or rough,
becoming very rough later in southwest. Rain or showers. Good, occasionally
poor.

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Nov 2011 22:26:26 +0100 (MET)

>    TLS server cert look acceptable by a simple DNS spoof and give clients a

But more importantly, believing in TLSA infos for which no DNSSEC validation
can be performed might significantly impair interoperability.
The IETF is about *improving* interop, not about reducing robustness
and making things brittle.

There might be simple, non-malicious, technical reasons (middle-boxes,
firewalls, filtering) why a TLS client might not obtain all of the TLSA
records that the DNS domain owner actually published and which would
be visible to someone with unimpaired internet connectivity.

Only when the DNSSEC signature verification succeeds we can be sure to
have *ALL* of the data that the DNS domain owner published and unaltered.
And only then we should take that information into consideration.

Everything else amount to reading coffee grounds and may seriously
impair the robustness of the infrastructure.

If the client gets to see only some of that data, but not the necessary
information, and a brittle DANE client aborts with "DANE validation failed",
then the user at the client will call up the server admin to report
incorrect DANE configuration -- which is obviously completely wrong and
misleading in this situation, and the server admin can not repro the
problems (caused by the middlebox near the client), and would not
be able to fix them anyway.

If the TLS client instead reported "can not perform DANE validation,
incomplete data received", it would be accurate and significantly less
confusing to any support folks that a user of that TLS client might contact.

-Martin

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 18 Nov 2011 12:39:32 +0100

>   look fishy by a simple DNS spoof and have clients abort.

This is possible without DANE by spoofing the address record of the TLS server.

>   TLS server cert look acceptable by a simple DNS spoof and give clients a

Please note that my proposal was not about positive matching, only about negative matching where TLSA exists, but does not match the TLS server certificate. This is NOT about trusting type 0/1 usages more than today, it is about distrusting them in case a mis-match is found.

	jakob

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 18 Nov 2011 12:40:54 +0100

> confusing to any support folks that a user of that TLS client might contact.

I'm fine with such feedback to the user for the non-matching case. Actually almost any feedback/warning on non-match would be useful.

	jakob

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 Nov 2011 18:02:40 +0100 (MET)

> This is possible without DANE by spoofing the address record of the TLS server.

That is something _entirely_ different, because then you are, in fact,
talking to the wrong server, and aborting is perfectly correct.

> Please note that my proposal was not about positive matching, only
> about negative matching where TLSA exists, but does not match the
> TLS server certificate. This is NOT about trusting type 0/1 usages
> more than today, it is about distrusting them in case a mis-match is found.

I strongly believe the spec should not claim that such a pig could
fly.  I consider it likely that a non-negligible amount of implementors
would get someting quite different airborne from what you intend.

Personally, I think that the original design of TLS version negotiation
is far from rocket science, but anyhow the entire installed base of
Windows 7 and Windows 2008R2 has it wrong (that is several hundred
million installations according to MS marketing and statcounters).

What data do we have to make the bold claim that *all* TLS clients
behind firewalls and middleboxes will see exactly *ALL* or *NONE*
of the TLSA records and *nothing* in between?  Pestering a non-negligible
amounts of users with false alarms seems like a very bad idea and
will only further desensitize users.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 Nov 2011 18:36:26 +0100 (MET)

> would get someting quite different airborne from what you intend.

I'm seriously concerned about the proposed functionality.

A "failed" DANE validation of a usage type 0 or 1 cert is effectively
a repudiation of a PKIX-validating(!!) cert with a different means.

I don't know how "careless" CAs are acting when publishing certs
on revocation lists.  I would _not_ be surprised if they spend more
effort on verifying the authenticity of revocations that they
spend on verifying DV certs, and I fail to remember the part of
PKIX and X.509 that says that one should entirely ignore when
process X.509v2 CRLs for revocations and that the signature
was only relevant for the "removeFromCRL" entries on the CRL.

Btw. based on discussion on the PKIX list, I realized that there
is likely a serious problem with usage type 0 TLSA records
because of how a number of PKIX-fanatic TLS clients have implemented
the processing of the Certificate handshake message in combination
with how awkwardly a lot of CAs and some PKI software manages
PKI credentials.

Identifying PKIX "intermediate CA" certs by certificate or certificate
hash (instead of subject public key info) is going to interfere badly
with certificate renewal (and cross-certification).

The only CAs cert where certificate/certificate-hash can be ensured
by the server admin to be in sync with the information published in DNS 
are either permanent trust anchors that are not renewed or cross-certified,
or those CA certs that the server sends within the forward certification
path of the server Certificate handshake message.

A number of TLS implementation appears to have the bad habit to
perform pretty unpredictable certificate path discovery that
includes a local pool of cached CA certs previously obtained
from other sources and some might extremely unreasonable things such
as AIA chasing, and those certs might get used _instead_ of those
sent by the server for the PKIX certificate path validation,
with the result that the DANE record for a CA cert/cert-hash
may not match the CA cert that the client ended up with after
PKIX path discovery voodoo.  Distribution of renewed intermediate
CA certs and subsitution with cross-CA certs will effectively
be random/chaotic throughout the installed base.  The only thing
that can only change synchronous with the update of the
server's certificate, is the public key that was used for signing
the server's certificate.

-Martin

---

From: Ondrej Mikle <[email-masked]>
Date: Sat, 19 Nov 2011 17:38:25 +0100

> the server's certificate.

Thanks for bringing this up again. Due to TLS client caching there's around
97000 "transvalid" certs that validate because of cached cert. Do you have a
(partial) list of TLS implementions/clients that do the caching? (browsers or
their TLS libraries mostly do this)

This "transvalidity feature/bug" happens mostly due to fact that the site
operators have no idea about the caching behavior - they see it works in their
browsers, but don't check a clean browser profile installation (I wonder what
good the caching should exactly do, except for making badly-configured servers
work).

AIA chasing? Out of curiosity, which TLS implementation does that?

Cross-certs and resigned certs: the amount of sites experiencing the swapping by
browser is quite vast. Most common are probably md2WithRsaEncryption Verisign
certs sent in server chain (which every modern browser swaps for the
sha1WithRsaEncryption version). There's at least tens of thousands such sites.
I'm guessing this will leave many people confused when setting up TLSA for their
sites and use one of those.

Is there some figure giving the amount of known multi-path certs or hosts?
(haven't seen one). I'll compute one from recently data in a bit.

I guess giving both pub_key_info and the hash would be ok (though that means
many records because of many hashes). Wouldn't just bare public key info suffice
(sorry I'm tired so there's probably something I'm missing).

Ondrej Mikle

---

From: Warren Kumari <[email-masked]>
Date: Sat, 19 Nov 2011 23:59:44 +0800

[ I'm writing this on the flight from NRT-> SFO and so am not fully caught up on the thread (and also sleep deprived), so apologies if things have already progressed / been settled… ]

Our AD mentioned that he had some discussions with IESG folk and they (strongly) expressed the view that if we don't have DNSSEC as a MUST, we are outside our charter (which seems to be fairly clearly true, unless one is willing to perform very create interpretation of the charter text…)

So far I am seeing strong consensus for:
If the outcome of the DNSSEC validation is "insecure" or "indeterminate", proceed as if the TLSA record doesn't exist.

There were some discussions on having DNSSEC as a MUST and then specifying behavior other than "revert to the same behavior as is there was no TLSA record" on "insecure" or "indeterminate". So far I haven't seen much consensus for this, and to me it also feels like we are violating the spirit of requiring DNSSEC. 

While I personally think that there is lots of utility in allowing for the restrictive use without DNSSEC, it is A: outside out charter and B: the WG has been clear that this doesn't belong in the protocol doc / doesn't want to discuss it now[0]

So, unless I hear lots of strong objections (or there has been substantive discussions while I've been in the air), it looks like we have consensus and can move on...

W

[0]: After we are done with protocol, if the WG is interested and want to, we can discuss rechartering and including this… or not…

---

From: Yoav Nir <[email-masked]>
Date: Sat, 19 Nov 2011 19:54:02 +0200

> their TLS libraries mostly do this)

TLS proxies also do this, because they need to perform a lot of handshakes with the same servers. Amazing how much of SSL traffic goes to gmail, and to a few popular banking sites.

> AIA chasing? Out of curiosity, which TLS implementation does that?

Lots of browsers and TLS proxies, because there is a non-trivial group of sites (if I was at work I could find a list) that send only the EE certificate, browsers and proxies need to check.

---

From: Warren Kumari <[email-masked]>
Date: Sat, 19 Nov 2011 23:59:44 +0800

W