Subject: [dane] Where to flesh out a DNSSEC extension proposal?

From: Chris Monteiro <[email-masked]>
Date: Sun, 26 Apr 2015 19:33:55 +0100

Hi all

Apologies is this in an inappropriate list, but I'm unfamiliar with the
channels for opening discussions about new web standards and this list
seemed least inappropriate. :)

I've blogged a proposal for a couple of DNS/ DNSSEC extensions that I would
be interested in taking forward to the next stage.

Would anyone be able to direct me to the correct channel for my proposal?
http://pirate.london/2015/04/using-dns-records-to-build-a-more-secure-web/

---

From: Paul Wouters <[email-masked]>
Date: Sun, 26 Apr 2015 14:37:08 -0400 (EDT)

On Sun, 26 Apr 2015, Chris Monteiro wrote:

> Apologies is this in an inappropriate list, but I'm unfamiliar with the channels for opening discussions about new web standards and this list seemed
> least inappropriate. :)
> 
> I've blogged a proposal for a couple of DNS/ DNSSEC extensions that I would be interested in taking forward to the next stage.
> 

Why publish HSTS information when you can publish the public key as well
using a TLSA record? Basically, the presence of a TLSA record means the
same as HSTS, "do connect with encryption please".

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 26 Apr 2015 19:41:33 +0000

> same as HSTS, "do connect with encryption please".

Yes, to harden opportunistic TLS via DNSSEC, use DANE TLSA RRs,
which for clients that support the approach kill two birds with
one stone:

    * Whether to authenticate
    * How to authenticate

    https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-16#section-2.2
    https://tools.ietf.org/html/draft-ietf-dane-srv-13#section-4

-- 
	Viktor.

---

From: Chris Monteiro <[email-masked]>
Date: Sun, 26 Apr 2015 21:50:32 +0100

Great, it looks like the proposed standard for hardening SMTP/TLS
could be repurposed for either http(s) or arbitrary ports as per my
proposal no?

Separate email thread for my alternate names suggestions?

On Sun, Apr 26, 2015 at 8:41 PM, Viktor Dukhovni <[email-masked]> wrote:
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Paul Wouters <[email-masked]>
Date: Sun, 26 Apr 2015 16:59:12 -0400 (EDT)

> could be repurposed for either http(s) or arbitrary ports as per my

There is nothing left to harden. The presence of TLSA means, never go
to the insecure port.

I tried to get this meaing into the original TLSA spec, and there was
resistence to it. It was sidetracked into the HASTLS record, which never
saw the light. I'm not sure if the DANE OPS (SRV) draft clarifies this,
but any sane client implementation of TLSA should really assume this.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 26 Apr 2015 21:26:14 +0000

> There is nothing left to harden. The presence of TLSA means, never go

Yes, when the client is not already committed to using TLS, i.e. it is
opportunistic.

> but any sane client implementation of TLSA should really assume this.

We don't currently have a generic "opportunistic DANE TLS" document,
the SMTP draft directly specifies this behaviour for SMTP.  The
SRV draft mostly does the same, withouth explicitly calling this
out as being opportunistic.

I expect the OPS draft LC to start any day now.  If it should
generalize this observation, this is a good time to suggest suitable
language.

When I started work on what is now the SMTP draft, it originally
was a generic opportunistic DANE TLS document.  It later split into
SMTP and OPS, with the former not covering non-SMTP use-cases, and
the latter not covering opportunistic security.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 26 Apr 2015 18:41:58 -0400 (EDT)

> Yes, when the client is not already committed to using TLS, i.e. it is

Unfortunately, the use of the standalone word "opportunistic" is
confusing as it means different things.

> generalize this observation, this is a good time to suggest suitable

I'm behind on my dane and dnsop document reading :(

> the latter not covering opportunistic security.

The opportune part is "hey, they are publishing a key to use for
crypto". Once you're at that stage, doing TLS is not optional, but
mandatory (IMHO, because people did not want to commit to this
in the original DANE RFC)

Paul

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 26 Apr 2015 18:46:15 -0400

> in the original DANE RFC)

Given https://tools.ietf.org/html/rfc7435 I don't see where there's ambiguity 
about what opportunistic is.

Scott K

---

From: Chris Monteiro <[email-masked]>
Date: Sun, 26 Apr 2015 23:51:34 +0100

Reading up on HASTLS, it appears at first glance that the ins-port /
sec-port etc combinations covers my use-case of advertising and
preferring a secure connection.

Is there any activity with HASTLS that I could contribute to?

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 26 Apr 2015 22:56:18 +0000

> Is there any activity with HASTLS that I could contribute to?

He's dead Jim.  TLSA records subsume whatever purpose HASTLS might
have served.  Long live the King.

-- 
	Viktor.

---

From: Chris Monteiro <[email-masked]>
Date: Mon, 27 Apr 2015 00:23:40 +0100

Right, so reading up on TLSA, I can see how the port, certificate and
certificate metadata are defined together and obviously I think this
is a great implementation to kill of CAs as we know them.

However, I don't see why the TLSA syntax must require the preferred
port AND the certificate hash as well. A systems administrator want to
only specify use of say 443/TLS whilst relying on the existing CA
system for certificate validation. Sure this is not where we want to
be long term, but allowing to implement partial TLSA features would
simplify things wouldn't it?

Therefore I believe my proposal is to allow a cut-down implementation
of TLSA for this purpose.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 26 Apr 2015 23:35:19 +0000

> is a great implementation to kill of CAs as we know them.

This is the DANE working group mailing list, I think this is off
topic.

> simplify things wouldn't it?

The administrator can use DANE-TA(2) or PKIX-TA(0) (whichever is
better applicable to the application protocol in question).  And
then need not publish the particular server certificate.

> of TLSA for this purpose.

No, you're just new to the issues, and have not thought them through
yet.  Take your time.  You can follow-up on [email-masked] if
you like, that's a user forum, not an IETF WG list.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 26 Apr 2015 21:16:28 -0400 (EDT)

> about what opportunistic is.

In Viktor's wording of "not already committed to using TLS" being equal
to opportunistic.

During the opportunistic (security) process you can become committed,
so the phrasing of committed versus opportunistic is a little
confusing/misleading, because opportunistic implies "can result in
plaintext".

In my view, using opportunistic can result in a commitment (hard fail) to TLS.

That's why I thought Viktor's choice of words were confusing.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 27 Apr 2015 02:50:43 +0000

> In Viktor's wording of "not already committed to using TLS" being equal

Sorry, "not initially/a-priori committed to using TLS".

> In my view, using opportunistic can result in a commitment (hard fail) to TLS.

100% agreement.

> That's why I thought Viktor's choice of words were confusing.

Sorry about that.

-- 
	Viktor.