Subject: [saag] Best way to store digital certificates and/or signatures in DNS

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 5 Feb 2018 19:53:29 -0500

(This is related to this draft:
https://tools.ietf.org/html/draft-foudil-securitytxt-02)

The proposed "security.txt" file has a matching optional
"security.txt.sig" file. One of the common issues we have received as
a feedback from potential users is a need to safeguard against the
possibility of an attacker compromising the webspace of a given
domain, and putting their own "security.txt" and "security.txt.sig"
files there. This will result in an attacker now receiving reports
about potential security issues in the compromised target.

One of the proposed ways to try to fix this issue is to use DNS as follows:
- to store the digital certificate that was used to generate the signature file
- OR to store the signature itself in DNS
- OR to store the entire "security.txt" file in a DNS record instead
of being accessible via the web

The logic behind this proposed solution is that web space tends to get
compromised more often and easier than DNS for any given domain.

What I am wondering if there are any currently best accepted practices
to accomplish these goals in DNS with minimum disruption to the
Internet architecture as whole. Possibilities I was thinking of is
using DANE and OPENPGPKEY records; CERT records, or perhaps even TXT
records like DKIM and SPF.

Any recommendations, suggestions or comments are welcome.

Thank you,
Yakov

---

From: Martin Thomson <[email-masked]>
Date: Tue, 6 Feb 2018 11:59:49 +1100

Have you considered formatting the signature as a certificate and
submitting it to a CT log?  That gives you an audit capability.

BTW, I noticed that the draft says SHOULD for HTTPS, which is a much
bigger hole than this.

On Tue, Feb 6, 2018 at 11:53 AM, Yakov Shafranovich
<[email-masked]> wrote:
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 6 Feb 2018 17:38:43 -0500

Hi Martin,

Thank you for the suggestion. Is there anyone today using the CT logs
system for tracking things other than certificate issuance?

Also, there is a question around ease of use. I was thinking that the
level of effort for an administrator to set this up should be about
the same as the level of effort required for setting up CAA, SPF,
DMARC or DKIM which involves setting up some DNS records. How easy
would it be to pull this off?

I also added an issue to track the HTTPS language here:
https://github.com/securitytxt/security-txt/issues/94

Yakov

---

From: Martin Thomson <[email-masked]>
Date: Wed, 7 Feb 2018 09:59:34 +1100

> system for tracking things other than certificate issuance?

https://wiki.mozilla.org/Security/Binary_Transparency

I believe that some people were not happy that this was even being
considered, so exercise caution.

> would it be to pull this off?

Ease of use is relative here.  You are talking about creating a
separate key and publishing that using a wholly different channel.
For the specifics, you would have to ask someone with more CT
experience than I.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 7 Feb 2018 16:45:41 +0100

On Tue, Feb 06, 2018 at 11:59:49AM +1100,
 Martin Thomson <[email-masked]> wrote 

> submitting it to a CT log?  That gives you an audit capability.

I wasn't present at the beginning, but it seems to me that the entire
point of security.txt was to have something light-weight? If we need
to set up CT logs or blockchains for it, doesn't it defeat the point?

---

From: Paul Wouters <[email-masked]>
Date: Wed, 7 Feb 2018 11:01:15 -0500

> system for tracking things other than certificate issuance?

I'm working on DNSSEC transparency, hope to have something for IETF 101 that
resolves questions raised before on this topic.

>>> records like DKIM and SPF.

How many times can the WEB depend on DNS(SEC) without claiming it is not depending on it?

If DNS is more trustworthy then content served by a webserver, then why not store the security
contact information only in DNS? Like SMIMEA or OPENPGP records for security@domain.

The new draft that adds an optional signature file is just not good enough. It still allows for
administrators to publish security information that is completely untrusted and spoofable.

In 2018 we should not do security protocol work that depends or allows unauthenticated data from any source.

The draft could fix this by making the signature mandatory as part of the .txt file.

But still, even when signed, a compromised server can use a false key that appears real, has been uploaded
to known pgp keyservers, etc. So it still needs to be anchored in some trustworthy external party.

We already see people using this file as an embedded LinkedIn advertisements. It will be just as horrible as
WHOIS free flow formats.

So, if we really want a standardized way to provide this information, go do this in RDAP. It does not depend
on the zone's DNS, does not depend on a compromised web server, and its format is meant to be very computer
consumable.

If that is "too difficult" for admins to do, then maybe security isn't their thing to begin with.

Paul

---

From: Tim Hollebeek <[email-masked]>
Date: Wed, 7 Feb 2018 19:03:07 +0000

Please do not abuse CT logs for non-certificate purposes.

Doing so is probably the fastest way to convince CT log operators to be
more restrictive about who they accept certificates from.  We don't want
that.

-Tim

> -----Original Message-----
> From: saag [mailto:[email-masked]] On Behalf Of Martin Thomson
> Sent: Monday, February 5, 2018 6:00 PM
> To: Yakov Shafranovich <[email-masked]>
> Cc: Ed Overflow <[email-masked]>; saag <[email-masked]>
> Subject: Re: [saag] Best way to store digital certificates and/or
signatures in
> DNS
submitting it
> to a CT log?  That gives you an audit capability.
> 
bigger
> hole than this.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 7 Feb 2018 22:45:59 +0000

>Please do not abuse CT logs for non-certificate purposes.

Exactly.  That's what the Bitcoin blockchain is there for.

Peter.

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 7 Feb 2018 22:21:00 -0500

> to set up CT logs or blockchains for it, doesn't it defeat the point?

The intent is certainly to be lightweight. The level of effort we were
targeting originally would be the same as required to put together a
"robots.txt" file, which also explains why the syntax is similar. For
the DNS piece, SPF is what comes to mind as an example for the level
of effort. As per Randy's proposal in the other thread, putting a hash
into a DNS record is probably around the level of effort targeted.

Thanks

---

From: Melinda Shore <[email-masked]>
Date: Wed, 7 Feb 2018 18:35:40 -0900

> resolves questions raised before on this topic.

It's possible to do <whatever> transparency without having to
shove stuff into CT logs, but it does mean that somebody is
going to have to run log servers for whatever application is
being transparencified.  FWIW it would be possible to build
something on top of Google's Trillian, although it may not be
what these folks want.  Transparency logs have some properties
that may or may not be suitable for this particular application,
but in any event I think it would be helpful if the authors
were more precise about what problem they're trying to solve by
storing digital signatures in the DNS (or transparency logs,
or ... ) and what properties are required in a solution.

Melinda

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 7 Feb 2018 22:44:56 -0500

> contact information only in DNS? Like SMIMEA or OPENPGP records for security@domain.

We do have an open issue about whether it is feasible to take this a
step further and shove the entire "security.txt" file into a DNS
record instead of serving it off the web. Haven't figured out yet on
whether that would break anything:
https://github.com/securitytxt/security-txt/issues/35

> If that is "too difficult" for admins to do, then maybe security isn't their thing to begin with.

I am not that familiar with RDAP - are the RDAP servers run by TLD
registries and RIRs only? And how would this work for domain admins -
would they need support from their registrar to put the info in, which
would then feed into the TLD registry?

Thanks

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Feb 2018 11:51:35 -0500

> https://github.com/securitytxt/security-txt/issues/35

I believe that shoving it all into DNS defeats the purpose.
Putting a hash in is a good recommendation, but don't count on it.

I think that the goal is allow end developers directly responsible for a web
service to directly put their contact info into place.

In a small entity, there was never really a problem, emailing "security@" or
abuse@, etc. is easy as the developers can go one cubicle over and get the
right address entered.

The issue is with bigger entities where the DNS is entirely a different
divisions' bailiwack, and just getting the right A/AAAA record entered for
api.foobar-division.example.com might have took three meetings and involved a
mandate from a VP.   So the SHA256 hash might make it in, eventually. Or not.

In fact, this even raises the question to me about using /.well-known!

Consider enties like google or microsoft, etc. where almost everything comes
in via "google.com/FOOBAR" and gets distributed by the front-end presentation
tier to one of many backends... I'd actually suggest that if you want to
report a problem with https://example.com/api/v2.4/redshift/blueshift/432, that
you try URLs like:
    https://example.com/api/v2.4/redshift/blueshift/security.txt
    https://example.com/api/v2.4/redshift/security.txt
    https://example.com/api/v2.4/security.txt
    https://example.com/api/security.txt
    https://example.com/.well-known/security.txt

because that would let the internal group put the most specific pointer
possible in without having to deal with bureaucracy elsewhere.

That is afterall the issue: the bureaucracy is opaque and often lossy
and reports go astray.   The goal is to short-circuit things.

    > would then feed into the TLD registry?

Yeah, it is intended to replace WHOIS/RWHOIS, which has not been that
successfully distributed.  It's common that RIR's have a pointer to BIG-ISP
for some /8 block, and that works.  But the intention is that BIG-ISP will
then delegate to small-ISP some /20 block, and even to end-customer the /24
such that the info is correct.

But, BIG-ISP doesn't want to put a list of their customers online, so abuse
reports do not get through.

RDAP makes the WHOIS data structured, but doesn't make it any more likely
that end-customer's data will be correct.  RDAP involved more bureaucracy
than putting the contact info in DNS.

I'm all for promoting it's use, but it will only be reliable where all layers
of the end-customer are diligent and responsible.  We'd be preaching to the
choir here.  What I think security.txt's goal is to allow a tuneful solo-ists
in a discordant choir to be discovered despite the conductor attention being
elsewhere.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Martin Thomson <[email-masked]>
Date: Fri, 9 Feb 2018 12:53:44 +1100

I thought that this would be a certificate.  Maybe one with a new KU bit.

---

From: Tim Hollebeek <[email-masked]>
Date: Fri, 9 Feb 2018 15:26:42 +0000

CT logs are for auditing publicly trusted certificates issued by certificate
authorities.

Do not abuse them.  Do not play games with EKUs to encapsulate random
data into certificates.

If we want *-transparency logs, perhaps based on the same software, then
discuss that.  But don't use the existing CT logs for anything other than 
their
stated purpose.

-Tim

> From: Martin Thomson [mailto:[email-masked]]
> Sent: Thursday, February 8, 2018 6:54 PM
> To: Tim Hollebeek <[email-masked]>
> Cc: Yakov Shafranovich <[email-masked]>; Ed Overflow
> <[email-masked]>; saag <[email-masked]>
> Subject: Re: [saag] Best way to store digital certificates and/or signatures 
> in
> DNS
>
> On Thu, Feb 8, 2018 at 6:03 AM, Tim Hollebeek <[email-masked]>
> wrote:
> > Doing so is probably the fastest way to convince CT log operators to
> > be more restrictive about who they accept certificates from.  We don't
> > want that.
> >
> > -Tim
> >
> >> > "security.txt.sig" file. One of the common issues we have received
> >> > as a feedback from potential users is a need to safeguard against
> >> > the possibility of an attacker compromising the webspace of a given
> >> > - OR to store the entire "security.txt" file in a DNS record
> >> > instead of being accessible via the web
> >> >
> >> > The logic behind this proposed solution is that web space tends to
> >> > get compromised more often and easier than DNS for any given domain.
> >> >
> >> > What I am wondering if there are any currently best accepted
> >> > practices to accomplish these goals in DNS with minimum disruption
> >> > to the Internet architecture as whole. Possibilities I was thinking
> >> > of is using DANE and OPENPGPKEY records; CERT records, or perhaps
> >> > even TXT records like DKIM and SPF.
> >> >

---

From: Melinda Shore <[email-masked]>
Date: Fri, 9 Feb 2018 10:11:55 -0900

> Do not abuse them.  Do not play games with EKUs to encapsulate random

Well, a bit late for that.  More to the point there's
currently no policy that prevents folks from doing just
that and I think it would be difficult to construct one
that couldn't be trivially gamed.  This is one of those
cases where providing a usable alternative can stop this
and there isn't enough entrenched existing practice to
break much if a good alternative is provided in a timely
way.  I've mentioned Google's "General Transparency"
project before and I'll mention it again.  I'm not sure
it's quite the right approach here but I don't think it's
terribly wrong.

Melinda

---

From: Paul Wouters <[email-masked]>
Date: Fri, 9 Feb 2018 16:47:16 -0500

> would then feed into the TLD registry?

RDAP is a WHOIS replacement. It can (soon MUST)  be used by RIR's and Registrars.

In this case I was thinking of Registrars.

While that does not address the subdomains potentially going to a different security
contact from the main domain, I personally don't see much value in random sysadmins in
an organization throwing up random webservers with their security.txt. If those servers
are compromised, it will include compromising security.txt but more likely the server
will be forgotten, the security contact will have left the company, and the security.txt
content is useless.

A valuable security contact is a contact that is known to be a stable reference before any
incident happens. Again, taking twitter as example, I'm much better of contacting the company's
twitter account (which will be a visible and stable entity) then follow the information of
security.txt found on a random (and insecure!) server.

I also think the entity's home page's "contact" link would be a more reliable method of finding
a proper contact. Sure, it is not an automated method. But automated contacts (like those in WHOIS/RDAP)
also get so much spam these email addresses are often abandoned anyway.

In short. The idea is cute but I see no practical value. I do see it as an additional danger of
people trusting untrusted information.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Feb 2018 17:07:22 -0500

> will be forgotten, the security contact will have left the company, and the security.txt

I don't think this is the use case for security.txt.

    > security.txt found on a random (and insecure!) server.

That's true for some entities, but very much untrue for others.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Paul Wouters <[email-masked]>
Date: Tue, 13 Feb 2018 12:24:59 -0500

On 02/09/2018 05:07 PM, Michael Richardson wrote:
> I don't think this is the use case for security.txt
The draft states:

	Security.txt defines a standard to help organizations define the process for security
	researchers to securely disclose security vulnerabilities.

Note "securely". It does not actually do that. It insecurely presents contact information that has
a higher change of having been modified by the attacker since the service is in need of a security
researcher contacting them about a vulnerability. You would hope the security researcher would find
a more secure avenue of contacting the owner of the web service in question.

> That's true for some entities, but very much untrue for others.

security that sometimes work, doesn't work.

There is no reason to believe security.txt will be better maintained then the "contact" link on the
website, or the abuse/security contact in WHOIS (or RDAP). And since it is guaranteed to be of an
equal or weaker security level then every other contact method currently available.

Like I said, it is a cute idea, but not a good idea.

Paul