Subject: [therightkey] TLSA Cert. Usage

From: Alexander Gurvitz <[email-masked]>
Date: Mon, 22 Oct 2012 10:44:06 +0200

Hello.

I don't quite understand what is the purpose of Cert. Usage 0 and 1 TLSA
records ("CA constraint" and "Service Certificate Constraint"). If we trust
DNSSEC and TLSA, we need no CA at all, and if we don't trust DNSSEC/TLSA,
what's the purpose of having any information in the TLSA ? The only place
such CA/cert. constraint makes sense to me is the certificate itself, HSTS,
or some checkbox in a browser setup.

Alexander Gurvitz,
net-me.net

---

From: Ben Laurie <[email-masked]>
Date: Mon, 22 Oct 2012 12:42:33 +0100

> or some checkbox in a browser setup.

Two of these three don't make any sense to me!

A CA/cert constraint in the certificate seems pointless - for a start,
the cert is already signed by some particular CA, and secondly, why
would an evil certificate constrain itself into non-operation?

Likewise, checkbox in browser setup - what would this checkbox do?
Pick a CA for every site on the 'net? How?

CAs have been arguing in other venues that using TLSA to validate in
the browser is inferior to using CAs because CAs are prepared to
revoke certificates that are used for bad things, whereas DNS
registrars/ICANN are not.

OTOH, CAs don't necessarily even no they've issued a cert to revoke,
if we look at history. And, of course, not all CAs have the same view
of what is bad.

This is, of course, why Certificate Transparency exists, so everyone
can see what's going on. Neither TLSA nor CAs are adequate, IMO.

---

From: James Cloos <[email-masked]>
Date: Mon, 22 Oct 2012 08:22:52 -0400

>>>>> "AG" == Alexander Gurvitz <[email-masked]> writes:

AG> I don't quite understand what is the purpose of Cert. Usage 0 and 1
AG> TLSA records ("CA constraint" and "Service Certificate Constraint").

The idea was for something akin to pinning.

Some only wanted to prevent rogue CAs in the bowsers' sets from
affecting them.

Others of us wanted to replace the CA concept with a trust path to
the dnssec root.

The four possible usage types are the resulting compromise.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Alexander Gurvitz <[email-masked]>
Date: Mon, 22 Oct 2012 14:37:38 +0200

Hello

As of the checkbox I meant something like -
[ ] Trust DANE w/o CAs
[ ] Trust CAs w/o DANE
I.e. globally, not per domain. I admit it's not very practical.

As for self-constrained cert, assume the private key is compromised.
Now I tell my CA to revoke the certificate, and with DNSSEC I can't revoke
and have to wait.
If the certificate "constrains itself" to require a CA validation, having
signed TLSA will not prevent me from revoking it.

Actually now I see that this is also answers my own question why we need
usages 0 and 1 - they allow CA-based revocation
in case of the private key compromise.

I wonder if it's the only scenario which benefits from usage 0/1 ?

Actually what made me ask is the following statement in
http://tools.ietf.org/html/rfc6394#section-3.1

> Continuing to require PKIX validation also limits the degree to which
> DNS operators (as distinct from the holders of domains) can interfere
> with TLS authentication through this mechanism. As above, even if a
> DNS operator falsifies DANE records, it cannot masquerade as the
> target server unless it can also obtain a certificate for the target
> domain.

I wonder how the fact that I created one record with use case 0,
prevents my DNS operator from creating a false record with use case 2.

Alex

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 22 Oct 2012 09:59:57 -0400

None of them make any sense to me.

The problem with DANE is that they had two agendas and only made one public
when they asked for the group to be formed. What they purported to be doing
was to make it possible to use the DNSSEC to establish keys. What they were
really about was trying to replace CAs.

One consequence of that positioning was that they could not accept any
advice from any of the people who work with CAs as they imagined all such
advice was designed to sabotage their efforts. Which meant that they began
by cutting themselves off from all advice from people with practical
experience of what they were attempting to do.

The key usages are the product of their ideological baggage. The
descriptions are confused because the thinking behind them is confused. It
is one of those plans that begins 'well first lets knock down all the
buildings and then decide what to replace them with'. Problem is that
people who start with that sort of plan rarely get beyond the first stage
of knocking everything down. Downtown Niagra being a prime example of the
result of that type of thinking.

CT seems a much better idea because it is designed to reinforce the
existing infrastructure rather than define it as the problem.

The big problem with DANE is that it relies on people putting correct
information into the DNS and keeping it correct even when it is going to
have (initially) marginal impact on functionality. Information in DANE
could be useful for some parties to use to curate certificate data in
combination with other data but it isn't viable for client enforcement in
an end to end model.

CT data is much better for enforcement as it is going to be managed by a
small circle of parties who are specialists in managing that type of data.

Any plan that relies on the typical Webmaster doing anything different is
unlikely to succeed. They already have more problems than anyone in IETF
land can imagine.

On Mon, Oct 22, 2012 at 7:42 AM, Ben Laurie <[email-masked]> wrote:

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

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

---

From: Paul Wouters <[email-masked]>
Date: Mon, 22 Oct 2012 10:52:07 -0400 (EDT)

On Mon, 22 Oct 2012, Phillip Hallam-Baker wrote:

> One consequence of that positioning was that they could not accept any advice from
> any of the people who work with CAs as they imagined all such advice was designed
> to sabotage their efforts. Which meant that they began by cutting themselves off
> from all advice from people with practical experience of what they were attempting
> to do.

We listened Phillip. In fact, we bend over backwards for the PKIX people,
and you got various Usage types specifically to support the CA model. The
fact that this model has diminishing returns is something you can behind
bring up at CABforum's reconfirmed closed doors.

> The big problem with DANE is that it relies on people putting correct information
> into the DNS and keeping it correct

Luckilly, people already need to do that and have years of experience of
putting the right data in DNS.

> even when it is going to have (initially)
> marginal impact on functionality. Information in DANE could be useful for some
> parties to use to curate certificate data in combination with other data but it
> isn't viable for client enforcement in an end to end model.

Now who's levelling downtown Niagra?

> Any plan that relies on the typical Webmaster doing anything different is unlikely
> to succeed.

The webmaster just needs to stick to the same "CA", whether a private
one, or one from CABforum. I fail to see the rocket science here, though
there is clearly the appearance of a smoke screen here.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 22 Oct 2012 12:00:25 -0400 (EDT)

> registrars/ICANN are not.

Of course, the registrant/DNS hoster itself _can_ and _should_ remove
the TLSA record from DNS. Either when it used TLSA for pinning and the
CA got compromised, or when the DNS provider itself got compromised.

> can see what's going on. Neither TLSA nor CAs are adequate, IMO.

I haven't yet read the draft. The tricky thing of not trusting the
publisher of the certificate data (eg the DNS hoster or web admin)
is one of timing, false positives and delegated (implicit) trust to
more third parties.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 22 Oct 2012 12:12:05 -0400

Well you listened and then made sure you did the opposite. So I decided
that engagement was counterproductive.

One of the things I have learned in the crypto world is that getting people
to use crypto is very very hard. In fact we are both using email right now,
we both know plenty of ways to use signatures and encryption but neither of
us is doing that.

Creating an ecosystem in which people use crypto is much much harder than
making the out of pocket cost zero. PGP had that 25 years ago and look
where use of GPG is today.

On Mon, Oct 22, 2012 at 10:52 AM, Paul Wouters <[email-masked]> wrote:

>> advice from
>> information
>> unlikely

---

From: Rick Andrews <[email-masked]>
Date: Mon, 22 Oct 2012 14:54:10 -0700

> CA got compromised, or when the DNS provider itself got compromised.

I'm one of the CAs that have been arguing in other venues that using TLSA w/o PKIX validation is inferior to using CAs (w/ PKIX validation). Having an established mechanism for revocation is just one of the reasons I believe this. There are other reasons:

-	CA-issued certs will conform to CABF Baseline Requirements (minimum key size, strong signing and hashing algorithm, acceptable validity period, proper extensions). Most people would agree that an SSL cert shouldn't be used for more than a few years, but there's no provision in DANE for preventing long-term use of a single key.

-	CA-issued certs would be very likely to have undergone automated checks for weak keys, weak exponents, not on Debian weak key list, not on internal phish lists, etc.) But with DANE w/o PKIX, it's almost certain that no checking was performed for weak keys. The person who generated the key probably won't, and the DNS operator probably won't either, because they're not required to. 

-	If you move away from the CA model to a DNSSEC-based DANE w/o PKI, you're shifting your trust to the operators of the various DNS zones and domains (for DNSSEC PKI) and to millions of individual domain owners (for generating and maintaining their keys). None of those entities are subject to audit like the CAs are, and it's reasonable to assume that without standards we'll have good ones and bad ones. That makes the end user less safe, in my opinion.

I actually like DANE. I think that it's a great addition to PKIX validation, but not a substitute for it. If we allow sites to use DANE w/o PKIX, I believe we're opening the door to poor PKI practices (which arguably have been tightened up over the past few years by CABF). We're also allowing attackers/phishers to create fraudulent web sites with SSL certs that appear to be as trusted as legitimate sites.

> > can see what's going on. Neither TLSA nor CAs are adequate, IMO.

I presume that CT will allow an auditor to see the actual cert that was issued, so an auditor could take over some of the functions that a CA currently performs (checking for key size, weak exponent, Debian, key lifetime, etc.). But CT doesn't require anyone to do that, nor does it impose any requirements on the auditor.

-Rick

---

From: Paul Wouters <[email-masked]>
Date: Mon, 22 Oct 2012 18:15:19 -0400 (EDT)

On Mon, 22 Oct 2012, Rick Andrews wrote:

> I'm one of the CAs that have been arguing in other venues that using TLSA w/o PKIX validation is inferior to using CAs (w/ PKIX validation). Having an established mechanism for revocation is just one of the reasons I believe this.

How is replacing the TLSA record not equal to revocation, except within
the middle man delays?

> -	CA-issued certs will conform to CABF Baseline Requirements (minimum key size, strong signing and hashing algorithm, acceptable validity period, proper extensions). Most people would agree that an…

That seems more like a local policy to me. It has also been called
"Frequent Rollover Syndrome" by some.

> -	CA-issued certs would be very likely to have undergone automated checks for weak keys, weak exponents, not on Debian weak key list, not on internal phish lists, etc.) But with DANE w/o PKIX, it's…

Systems now would "very likely" not generate insecure stuff. CA's have
been pretty good at issuing bad certificates. I find this argument
pretty weak. The market has shown a strong preference for the CA with
the least amount of checks, delivering a cert in seconds rather then
hours or days - not a mechanism to build up security.

> -	If you move away from the CA model to a DNSSEC-based DANE w/o PKI, you're shifting your trust to the operators of the various DNS zones and domains (for DNSSEC PKI) and to millions of individual…

Yes, and you are right we are adding new risk points. But those are much
fewer (root, .com, registrar webgui, DNS hoster) then the plethora of
CA's. But still, DANE allows you to do both, so we can all be hapy.

Maintaining TLS certificates actually becomes _easier_, because people
don't have to frantically read the openssl man page to generate a new
certificate when the old one suddenly expired without anyone noticing
before the complains hit the help desk.

> I actually like DANE. I think that it's a great addition to PKIX validation, but not a substitute for it. If we allow sites to use DANE w/o PKIX, I believe we're opening the door to poor PKI practi…

If only CABF was open, I could actually try and reason with you to see
if you are right. Unfortunately, CABF recently comitted to remain
closed.

As for your "if we allow DANE w/o PKIX" comment, the DANE RFC does allow
it, and with good reason. Contrary to your claim, it will actually
_increase_ TLS security by being able to phase out self-signed cert
popups for those people who can't or don't want to pay the CA industry.
The payment system is frankly the main course of reduced TLS security,
and DANE fixes that nicely.

This does not stop you from your business model. You can remain issuing
EV certs, browsers can provide additional colouring signifying the
additional checks done by CABF, and people can add TLSA records to pin
it to a single CA to not be affected by another CA's compromise.

Saying the masses can't have 'secure websites' because it would enable
the bad guys to have 'secure websites' is not a strong argument.
Following that, we get governments banning encryption altogether.

Paul

---

From: "Ryan Sleevi" <[email-masked]>
Date: Mon, 22 Oct 2012 15:25:36 -0700

On Mon, October 22, 2012 2:54 pm, Rick Andrews wrote:
>  I'm one of the CAs that have been arguing in other venues that using TLSA
>  w/o PKIX validation is inferior to using CAs (w/ PKIX validation). Having
>  an established mechanism for revocation is just one of the reasons I
>  believe this. There are other reasons:
>
>  -	CA-issued certs will conform to CABF Baseline Requirements (minimum key
>  size, strong signing and hashing algorithm, acceptable validity period,
>  proper extensions). Most people would agree that an SSL cert shouldn't be
>  used for more than a few years, but there's no provision in DANE for
>  preventing long-term use of a single key.

Nor is there any effective provision in the CA model for key
cryptoperiods. If a CA denies reissuance to a customer because they tried
to reuse an existing key, the end user need simply go to another CA. Given
that nearly all CAs are equal in trustworthiness from the client
perspective, this is not in fact an active mitigation provided by CAs.

Keysize and hashing requirements are already implemented in clients -
Chromium, Safari, Mozilla, and Microsoft have moved to deprecate MD5 and <
1024 bit certificates. I imagine that these requirements will continue to
roll forward - primarily gated by the limitations of the existing deployed
infrastructure and the need to not break all of the sites with
legitimately-issued WebPKI certificates.

>
>  -	CA-issued certs would be very likely to have undergone automated checks
>  for weak keys, weak exponents, not on Debian weak key list, not on
>  internal phish lists, etc.) But with DANE w/o PKIX, it's almost certain
>  that no checking was performed for weak keys. The person who generated the
>  key probably won't, and the DNS operator probably won't either, because
>  they're not required to.

Agreed. This is an understandable benefit of having a third-party mediate
key issuance.

>
>  -	If you move away from the CA model to a DNSSEC-based DANE w/o PKI,
>  you're shifting your trust to the operators of the various DNS zones and
>  domains (for DNSSEC PKI) and to millions of individual domain owners (for
>  generating and maintaining their keys). None of those entities are subject
>  to audit like the CAs are, and it's reasonable to assume that without
>  standards we'll have good ones and bad ones. That makes the end user less
>  safe, in my opinion.

Out of curiosity, given that both DV and EV ultimately rely on the
validity of the domain registration information, what is to prevent a
malicious DNS zone from compromising or otherwise maliciously requesting a
certificate? That is, as the zone operator for .com, is there any more or
less risk with DNSSEC that I may lie about who owns victim.com? If I can
lie about who owns victim.com, I can induce a WebPKI CA to issue a (domain
validated) certificate for victim.com.

The DNS zone operator remains in a privileged position in the PKIX world,
since PKIX ultimately relies on the validity of the DNS registry as a key
part of performing validation checks. Yes, EV improves these checks, but
there is still an inherent reliance on "party X is authorized to request
for victim.com"

As far as being vulnerable to the millions of sites' key management
practice - again, how is that different than the existing PKIX model? With
the exception of EV Code Signing, no documents produced by the CA/B Forum
require, for end-entity certificates, the use of an HSM or otherwise
secure key management.

I can appreciate the concern for /usability/ - which is, indeed, a clear
and real issue with ANY form of key management. But the suggestion of
audit being part of the concern, given that the vast majority of sites
happily store the private key unencrypted on the web host machine, seems
like a bit of a stretch.

>  I actually like DANE. I think that it's a great addition to PKIX
>  validation, but not a substitute for it. If we allow sites to use DANE w/o
>  PKIX, I believe we're opening the door to poor PKI practices (which
>  arguably have been tightened up over the past few years by CABF). We're
>  also allowing attackers/phishers to create fraudulent web sites with SSL
>  certs that appear to be as trusted as legitimate sites.

Has the work been to tighten up the poor PKI practices of end users, or
the poor PKI practices of CAs?

---

From: Rick Andrews <[email-masked]>
Date: Mon, 22 Oct 2012 15:35:21 -0700

> > I'm one of the CAs that have been arguing in other venues that using
> TLSA w/o PKIX validation is inferior to using CAs (w/ PKIX validation).
> Having an established mechanism for revocation is just one of the
> reasons I believe this.
> 

It's similar, except that all CAs document their revocation process and reasons in their CPS documents. It's very transparent and understood. Have DNS providers documented their process and reasons for removing a TLSA record? Who monitors them to make sure they're doing it properly, or at least doing it according to a documented process?

> if you are right. Unfortunately, CABF recently comitted to remain

This is a mischaracterization. The CABF did not recently commit to remain closed. It became more open, just not open enough for some people. Even if we disagree on that, why can't we discuss this issue in this forum?

-Rick

---

From: Chris Palmer <[email-masked]>
Date: Mon, 22 Oct 2012 15:56:47 -0700

> if you are right. Unfortunately, CABF recently comitted to remain

There is a public mailing list, where real stuff is discussed, and
it's worth joining.

https://cabforum.org/mailman/listinfo/public

https://cabforum.org/pipermail/public/

I personally wanted and worked for more of a change, but what we did
get is better than the previous status quo.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 22 Oct 2012 19:02:23 -0400 (EDT)

> It's similar, except that all CAs document their revocation process and reasons in their CPS documents. It's very transparent and understood. Have DNS providers documented their process and reasons…

The registrant either is the DNS operator, or has sourced it out to
a DNS operator that already has full control to take over the
sites, document changelogs, etc. For the registrant, this adds no new
requirement. The reason the CA's need such documentation, is because it
is an addition to the process the registrant needs to be able to audit.

> This is a mischaracterization. The CABF did not recently commit to remain closed. It became more open, just not open enough for some people. Even if we disagree on that, why can't we discuss this i…

We can discuss it, but statements on how well CAs do certain things is
something I cannot validate. That's all I was saying.

Paul

---

From: Carl Wallace <[email-masked]>
Date: Tue, 23 Oct 2012 00:10:40 +0100

>There is a public mailing list, where real stuff is discussed, and

It's worth noting that "for the time being, the list is read-only for
non-members."

---

From: Chris Palmer <[email-masked]>
Date: Mon, 22 Oct 2012 16:41:50 -0700

> It's worth noting that "for the time being, the list is read-only for

Yep, that's a bummer. Ultimately the CABF is planning to allow
read-write access, after subscribers have clicked through an IP rights
agreement. But that is also pending, alas.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Oct 2012 01:30:40 +0100

I think we've wandered off-topic here folks.
CAB forum might be wonderful, or they might
not be, but that's not our business nor is
it something that ought drive the CT Bof
which is the op-topic thing for this list
right now.

Feel free to argue with me about that, but
off-list please.

Thanks,
S.

---

From: Gervase Markham <[email-masked]>
Date: Tue, 23 Oct 2012 09:41:11 +0100

> before the complains hit the help desk.

They have to read other documentation about how to update their DNS 
instead...

On the above point, incidentally, for those who are not capable of 
putting an entry in their calendars for a year or two years in advance, 
then the following Firefox addon (rough and ready, but functional) might 
be useful:

https://addons.mozilla.org/en-US/firefox/addon/expiry-canary/

Gerv

---

From: Ben Laurie <[email-masked]>
Date: Tue, 23 Oct 2012 10:08:31 +0100

On 22 October 2012 17:00, Paul Wouters <[email-masked]> wrote:
> the TLSA record from DNS.

Why would a criminal revoke their own certificate?

> Either when it used TLSA for pinning and the

---

From: Ben Laurie <[email-masked]>
Date: Tue, 23 Oct 2012 10:14:10 +0100

On 22 October 2012 22:54, Rick Andrews <[email-masked]> wrote:
> -       If you move away from the CA model to a DNSSEC-based DANE w/o PKI, you're shifting your trust to the operators of the various DNS zones and domains (for DNSSEC PKI)

How is this different from DV certs? In some ways DV is worse, surely,
since an attacker only has to own my domain temporarily and locally
(to the CA) to get a DV cert issued.

> and to millions of individual domain owners (for generating and maintaining their keys).

Domain owners already generate their keys, don't they?

> None of those entities are subject to audit like the CAs are, and it's reasonable to assume that without standards we'll have good ones and bad ones. That makes the end user less safe, in my opinion.

We appear to have bad CAs despite standards.

> I presume that CT will allow an auditor to see the actual cert that was issued,

Something very like the cert, anyway - where the SCT is issued from a
pre-certificate, then that's what the log records, not the actual
certificate.

> so an auditor could take over some of the functions that a CA currently performs (checking for key size, weak exponent, Debian, key lifetime, etc.). But CT doesn't require anyone to do that, nor does it impose any requirements on the auditor.

CT _could_ impose requirements. I suspect people will monitor these
things anyway, though.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 23 Oct 2012 10:15:29 +0100

On 22 October 2012 17:00, Paul Wouters <[email-masked]> wrote:
> I haven't yet read the draft.

Well, you should.

> The tricky thing of not trusting the

I'm not sure if this is a comment on the draft you haven't read, or
something else?

---

From: Rick Andrews <[email-masked]>
Date: Tue, 23 Oct 2012 10:35:00 -0700

> -----Original Message-----
> From: Ben Laurie [mailto:[email-masked]]
> Sent: Tuesday, October 23, 2012 2:14 AM
> To: Rick Andrews
> Cc: Paul Wouters; [email-masked]
> Subject: Re: [therightkey] TLSA Cert. Usage
> 
> reasons I believe this. There are other reasons:
> >
> > -       CA-issued certs will conform to CABF Baseline Requirements
> (minimum key size, strong signing and hashing algorithm, acceptable
> validity period, proper extensions). Most people would agree that an
> SSL cert shouldn't be used for more than a few years, but there's no
> provision in DANE for preventing long-term use of a single key.
> >
> > -       CA-issued certs would be very likely to have undergone
> automated checks for weak keys, weak exponents, not on Debian weak key
> list, not on internal phish lists, etc.) But with DANE w/o PKIX, it's
> almost certain that no checking was performed for weak keys. The person
> who generated the key probably won't, and the DNS operator probably
> won't either, because they're not required to.
> >
> > -       If you move away from the CA model to a DNSSEC-based DANE w/o
> PKI, you're shifting your trust to the operators of the various DNS
> zones and domains (for DNSSEC PKI)
> 

DV is no better at preventing attacks from those who can subvert DNS. The point I was trying to make is that with any CA-issued cert, a set of checks will be performed on the key and other cert contents that will not happen if the cert is self-signed.

> Domain owners already generate their keys, don't they?

Yes, but with DANE w/o PKIX I have to trust that the domain owners with self-signed certs did everything right when generating their keys and certs, because no one is checking them.
 
> > None of those entities are subject to audit like the CAs are, and
> it's reasonable to assume that without standards we'll have good ones
> and bad ones. That makes the end user less safe, in my opinion.
> 

True, and groups like OTA and CABF are trying to improve standards. I'm advocating improving the existing system rather than throwing it out and bringing in a new one that is not arguably less trustworthy.

This is a bit of a tangent, but IMO the browser vendors have not helped much to improve the status quo. They created a trust system in which all CAs are trusted equally, and they are reluctant to remove any CA's trusted roots from their browser. I'd like to brainstorm how those issues can be addressed.

> validation, but not a substitute for it. If we allow sites to use DANE
> w/o PKIX, I believe we're opening the door to poor PKI practices (which
> also allowing attackers/phishers to create fraudulent web sites with
> SSL certs that appear to be as trusted as legitimate sites.
> >
> > so an auditor could take over some of the functions that a CA
> currently performs (checking for key size, weak exponent, Debian, key
> lifetime, etc.). But CT doesn't require anyone to do that, nor does it
> impose any requirements on the auditor.
> 

I agree fully that CT would allow lots of actors to monitor everything. But what if you build it and they don't come?

-Rick

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 23 Oct 2012 13:52:02 -0400

> Yes, but with DANE w/o PKIX I have to trust that the domain owners with self-signed certs did everything right when generating their keys and certs, because no one is checking them.

This is a bizarre claim.  You seem to be arguing that the TLSA
operation is somehow intriniscally harder than configuring the DNS
correctly or doing DNSSEC.  What makes TLSA peculiarly hard?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Rick Andrews <[email-masked]>
Date: Tue, 23 Oct 2012 11:04:21 -0700

Andrew,

I'm not arguing about TLSA at all. I'm saying that even before the site owner asks their DNS provider to set up a TLSA record, if they create their own self-signed cert, no one verifies anything about this key or the cert contents. I have to trust that they did everything right (didn't use an unpatched Debian system, didn't reuse the same key they've been using for 10 years, didn't put misleading info into the DN, etc.)

-Rick

> From: [email-masked] [mailto:therightkey-
> [email-masked]] On Behalf Of Andrew Sullivan
> Sent: Tuesday, October 23, 2012 10:52 AM
> To: [email-masked]
> > Yes, but with DANE w/o PKIX I have to trust that the domain owners
> with self-signed certs did everything right when generating their keys
> and certs, because no one is checking them.
> >
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 23 Oct 2012 14:21:02 -0400

Any administrative procedure that crosses between multiple services in the
same organization has always proved to be very hard to pull off. Maybe it
should not be that way but that has been the experience.

DNSSEC could in theory just be a command line option to BIND. But putting
SSL certs in the zone file requires the admins of the Web server to talk to
the people running the DNS. And that proves to be very hard and it also
proves to be unreliable.

On Tue, Oct 23, 2012 at 1:52 PM, Andrew Sullivan <[email-masked]>wrote:

> > Yes, but with DANE w/o PKIX I have to trust that the domain owners with
> self-signed certs did everything right when generating their keys and
> certs, because no one is checking them.
> >
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 23 Oct 2012 14:41:42 -0400

> the people running the DNS. And that proves to be very hard and it also

Putting IP addresses into the zone file also requires the admins of the
web server to talk to the people running the DNS, but most people
somehow manage to get it done.  Those who don't, don't have a working
web server, because people can't find it on the 'net.

By extension, if DANE works, then those same web server admins who
somehow figured out how to communicate their IP addresses to the DNS
admins will also figure out how to communicate their public keys to
those same DNS admins.  Those who don't, don't have a working HTTPS
server, because people with DANE-enabled clients won't be able to
connect to it.

I'm not saying DANE is a perfect solution (i particularly don't like the
concentration of hierarchical power represented by the DNS), but the
objections raised here recently are pretty underwhelming.

	--dkg

---

From: Bill Frantz <[email-masked]>
Date: Tue, 23 Oct 2012 11:46:02 -0700

On 10/23/12 at 10:35 AM, [email-masked] (Rick 
Andrews) wrote:

>... IMO the browser vendors have not helped much to improve the 
>status quo. They created a trust system in which all CAs are 
>trusted equally, and they are reluctant to remove any CA's 
>trusted roots from their browser. I'd like to brainstorm how 
>those issues can be addressed.

Trust is such a nebulous idea. For example, I could trust by 
cousin to abuse alcohol before he died from alcohol-related causes.

What I think we are trying to do is ensure that the user can 
rely on the normal clues to people use to correctly identify a 
web site (or other computer-mediated communication). Probably 
users use different visual, and possibly audible clues, but 
probably the primary clue they use is the look and feel of the 
web page. How do we get our public key based trust system to 
separate out the fishing sites?

We have tried to train users to look at the browser's crome. To 
the extent we have been successful, we can now discuss how to 
improve both the use interface from the crome, and the 
underlying trust model that supports that interface. If we are 
going to assign differently levels of assurance to different 
CAs, we will need to reflect those different levels in the 
chrome UI.

One way to improve the underlying trust model is to use more 
that one identification technique. We currently use only the 
PKIX/CA system. As Rick points out, all CAs are equal as far as 
our trust model is implemented. If we could notice that the last 
time we visited this site, it had the same public key, that 
would improve trust, giving us two paths of recognition. If we 
also got the same information through DANE, that would give us 
three paths.

When these paths disagree, we have a problem. What do we do when 
the CA has issued a CRL with the site, but the public key is the 
same as the last time, and the site doesn't use DANE. What if 
site uses DANE and it says the key belongs to the site? Should 
we have more paths to establish identity, the number of 
possibilities will grow rapidly.

Consider a nearly real world trust establishment problem. My son 
is driving from California to Pittsburg PA to go to collage. I 
receive a communication from him saying the car has needed major 
repairs and to please send him $2000. How do I establish trust 
in this communication.

If the communication is two-way, a phone call for example, I can 
engage in a dialog similar to the security questions requested 
by web sites. If it is a voice call, I can use my built in voice 
recognition system.

If the "send to" address for the money in on a logical route 
between CA and PA, I'll react differently than if it is in Nigeria.

Etc. etc.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | Airline peanut bag: "Produced  | Periwinkle
(408)356-8506      | in a facility that processes   | 16345 
Englewood Ave
www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos, 
CA 95032

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Oct 2012 16:17:31 -0400 (EDT)

On Tue, 23 Oct 2012, Daniel Kahn Gillmor wrote:

> concentration of hierarchical power represented by the DNS)

The hierarchical problem is pretty much an enigma case. If the root key
or the com key ever gets abused, for instance by providing custom records
with signatures to target someone specifically, and such a record ever
leaks out for us to verify, they will lose that trust forever, and the
UN or some other body will step in with a new method and trust model.

If these keys get "stolen", I think everyone will probably assume what
really happened is the above paragraph.

That's why I trust the root key and Verisgn to do a good job.

This is the same principle where Queen Beatrix of The Netherlands in
theory can fire the government, while in practise it would be her last
time she could. (unlike Harper in Canada, but I digress)

What we will see in practise, is Registrar and Registry compromises,
where people simple add or replace DS records. I expect any fortune500
company to monitor their DNS for such abuse.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Oct 2012 16:55:41 -0400 (EDT)

> They have to read other documentation about how to update their DNS 

No they do not. Because there is no _expiry date_. By being in the TLSA
record in DNS, it is self-declared valid. No mysterious outages in 1 or
2 years from now when the certificat expired and the original guy who
know the openssl commandline left the company. This is another reason for
TLS bare key certificates that just contain the bare public key as SBKI.
To get rid of that obsolete container information (and new CA invoice).

Until those are common practise, define the certificate to be valid for
100 years, and you should be good till retirement.

Paul

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 23 Oct 2012 18:54:00 -0400

> UN or some other body will step in with a new method and trust model.

The global experience with CAs suggests that failure to prevent secret
key material abuse does not result in negative consequences for those
CAs that are "too big to fail".  I don't see why that experience
wouldn't repeat itself for the key that signs the root zone or any of
the popular TLDs.

Anyway, cryptographic failures are only one part of the problem.
Political failures are at least as important, and the DNS has already
shown itself to be vulnerable to manipulation by powerful actors [0].  i
see no reason to believe that this sort of manipulation would stop short
of malicious DS record insertion once DNSSEC is in widespread use.

Regards,

	--dkg

[0]
https://www.muckrock.com/foi/united-states-of-america-10/domain-name-seizures-329/#445469-responsive-documents

---

From: Michael Jenkins <[email-masked]>
Date: Tue, 23 Oct 2012 19:21:03 -0400

I don't think trust is that nebulous an idea for many things that people do
with browsers. We've got to stop convincing people that "this certificate
is okay", and start informing them "it's okay to enter a credit card number
here".

I often wonder why the browser doesn't have the ability for me to label my
trust anchors with labels like "bank" and "school", and then indicate to me
when a certificate validation has terminated in a labeled trust anchor. How
I apply those labels is my policy - based on prior experience, or obtaining
a "fingerprint" from a letter from the bank, or what have you. It doesn't
even prevent me from working with other banks, unless I want to limit
myself.

This would be even more useful for device apps, that could be initialized
to only use one trust anchor from the list.

There have got to be ways to do this that are fairly straightforward, not
too tedious for youth and not too complicated for elderly folks. [Have I
insulted everyone yet? Alrighty then.]

Mike

On Tue, Oct 23, 2012 at 2:46 PM, Bill Frantz <[email-masked]> wrote:

> On 10/23/12 at 10:35 AM, [email-masked] (Rick Andrews) wrote:
>
>  ... IMO the browser vendors have not helped much to improve the status
>> quo. They created a trust system in which all CAs are trusted equally, and
>> they are reluctant to remove any CA's trusted roots from their browser. I'd
>> like to brainstorm how those issues can be addressed.
>>
>
> Trust is such a nebulous idea. For example, I could trust by cousin to
> abuse alcohol before he died from alcohol-related causes.
>
> What I think we are trying to do is ensure that the user can rely on the
> normal clues to people use to correctly identify a web site (or other
> computer-mediated communication). Probably users use different visual, and
> possibly audible clues, but probably the primary clue they use is the look
> and feel of the web page. How do we get our public key based trust system
> to separate out the fishing sites?
>
> We have tried to train users to look at the browser's crome. To the extent
> we have been successful, we can now discuss how to improve both the use
> interface from the crome, and the underlying trust model that supports that
> interface. If we are going to assign differently levels of assurance to
> different CAs, we will need to reflect those different levels in the chrome
> UI.
>
> One way to improve the underlying trust model is to use more that one
> identification technique. We currently use only the PKIX/CA system. As Rick
> points out, all CAs are equal as far as our trust model is implemented. If
> we could notice that the last time we visited this site, it had the same
> public key, that would improve trust, giving us two paths of recognition.
> If we also got the same information through DANE, that would give us three
> paths.
>
> When these paths disagree, we have a problem. What do we do when the CA
> has issued a CRL with the site, but the public key is the same as the last
> time, and the site doesn't use DANE. What if site uses DANE and it says the
> key belongs to the site? Should we have more paths to establish identity,
> the number of possibilities will grow rapidly.
>
>
> Consider a nearly real world trust establishment problem. My son is
> driving from California to Pittsburg PA to go to collage. I receive a
> communication from him saying the car has needed major repairs and to
> please send him $2000. How do I establish trust in this communication.
>
> If the communication is two-way, a phone call for example, I can engage in
> a dialog similar to the security questions requested by web sites. If it is
> a voice call, I can use my built in voice recognition system.
>
> If the "send to" address for the money in on a logical route between CA
> and PA, I'll react differently than if it is in Nigeria.
>
> Etc. etc.
>
> Cheers - Bill
>
> ------------------------------**------------------------------**
> -------------
> (408)356-8506      | in a facility that processes   | 16345 Englewood Ave
> www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos, CA 95032
>
> ______________________________**_________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/therightkey<https://www.ietf.org/mailman/listinfo/therightkey>
>

---

From: Carl Wallace <[email-masked]>
Date: Wed, 24 Oct 2012 00:33:07 +0100

From:  Mike Jenkins <[email-masked]>
Date:  Wednesday, October 24, 2012 12:21 AM
To:  <[email-masked]>
Subject:  Re: [therightkey] Improving Trust

> with browsers. We've got to stop convincing people that "this certificate is
> okay", and start informing them "it's okay to enter a credit card number
> here".
> 
> when a certificate validation has terminated in a labeled trust anchor. How I
> apply those labels is my policy - based on prior experience, or obtaining a
> "fingerprint" from a letter from the bank, or what have you. It doesn't even
> prevent me from working with other banks, unless I want to limit myself.

This is along the lines of a browser feature I've wanted for a while  the
means for the user to indicate the nature of what they are doing  i.e., I'm
shopping or banking or doing medical stuff, etc.  A narrow trust anchor
store associated with purposes like these could allow the posture of the
browser to vary based on what the user says they are doing.

> 
> This would be even more useful for device apps, that could be initialized to
> only use one trust anchor from the list.
> 
> There have got to be ways to do this that are fairly straightforward, not too
> tedious for youth and not too complicated for elderly folks. [Have I insulted
> everyone yet? Alrighty then.]
> 
> Mike
> 
>>> ... IMO the browser vendors have not helped much to improve the status quo.
>>> They created a trust system in which all CAs are trusted equally, and they
>>> are reluctant to remove any CA's trusted roots from their browser. I'd like
>>> to brainstorm how those issues can be addressed.
>> 
>> Trust is such a nebulous idea. For example, I could trust by cousin to abuse
>> alcohol before he died from alcohol-related causes.
>> 
>> and feel of the web page. How do we get our public key based trust system to
>> We have tried to train users to look at the browser's crome. To the extent we
>> have been successful, we can now discuss how to improve both the use
>> points out, all CAs are equal as far as our trust model is implemented. If we
>> could notice that the last time we visited this site, it had the same public
>> key, that would improve trust, giving us two paths of recognition. If we also
>> got the same information through DANE, that would give us three paths.
>> 
>> When these paths disagree, we have a problem. What do we do when the CA has
>> issued a CRL with the site, but the public key is the same as the last time,
>> and the site doesn't use DANE. What if site uses DANE and it says the key
>> belongs to the site? Should we have more paths to establish identity, the
>> number of possibilities will grow rapidly.
>> 
>> 
>> Consider a nearly real world trust establishment problem. My son is driving
>> from California to Pittsburg PA to go to collage. I receive a communication
>> from him saying the car has needed major repairs and to please send him
>> $2000. How do I establish trust in this communication.
>> 
>> If the communication is two-way, a phone call for example, I can engage in a
>> dialog similar to the security questions requested by web sites. If it is a
>> voice call, I can use my built in voice recognition system.
>> 
>> If the "send to" address for the money in on a logical route between CA and
>> PA, I'll react differently than if it is in Nigeria.
>> 
>> Etc. etc.
>> 
>> Cheers - Bill
>> 
>> (408)356-8506 <tel:%28408%29356-8506>       | in a facility that processes
>> | 16345 Englewood Ave
>> www.pwpconsult.com <http://www.pwpconsult.com>  | peanuts and other nuts." -
>> Duh | Los Gatos, CA 95032
>> 
>> <https://www.ietf.org/mailman/listinfo/therightkey>
> 
> _______________________________________________ therightkey mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/therightkey

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 23 Oct 2012 19:42:50 -0400

> is okay", and start informing them "it's okay to enter a credit card number

browsers should not try to indicate "it's okay to enter a credit card
number here" without asking for a lot more information from the user --
even if you could determine that a given business was "official",
there's no way for a browser to know that this business is one that the
user actually is willing to give their credit card to.

The same word of caution holds for many other kinds of communication
beyond financial details.  Different users face different threats and
have different perceptions of acceptable risk.

> even prevent me from working with other banks, unless I want to limit

What you describe is known as "petnames" [0].  There was even a browser
plugin for it, back in the day [1].

If you want this functionality, perhaps resurrecting that plugin would
be a useful course of action?

Regards,

	--dkg

[0] http://www.skyhunter.com/marcs/petnames/IntroPetNames.html
[1] http://www.waterken.com/user/PetnameTool/

---

From: SM <[email-masked]>
Date: Tue, 23 Oct 2012 16:44:48 -0700

Hi Paul,
>leaks out for us to verify, they will lose that trust forever, and the

Yes.

Regards,
-sm

---

From: [email-masked] (Martin Rex)
Date: Thu, 25 Oct 2012 02:45:58 +0200 (CEST)

Paul Wouters wrote:
> Gervase Markham wrote:
>> Paul Wouters wrote:
> know the openssl commandline left the company.

This will still happen if the Web Server cert was issued with a validity
of only one year.

> 
> This is another reason for

Uh-oh, such a recommendation runs shivers down my spine and is
seriously ignorant of the real world.

Due to a uncounted numbers of bugs in software, some of which get published
on a monthly schedule, TLS-enabled Servers may experience break-ins,
and there is absolutely no indication that this is going to ever change.

So rather than making the keys last forever, the objective should
be to make rekeying (a) easy to perform by the staff and (b) performed
with sufficient frequency so that it will be a no-brainer for staff
to rekey after an alleged or verified security breaches on the server
(e.g. the virus-scanner detected malware on the machine).

-Martin

---

From: Paul Wouters <[email-masked]>
Date: Wed, 24 Oct 2012 22:30:43 -0400 (EDT)

> and there is absolutely no indication that this is going to ever change.

So replace your TLSA record in DNS to point to the new certificate. The
DNS is your OCSP/CRL/Revoke/Publish mechanism, but without the middle
man delay and payments.

> So rather than making the keys last forever

Keys, using the SPKI certificate format, have no expiry date. They don't
last forever, they last as long as the DNS backs them up.

Paul