Subject: [dane] making ietf.org eat the DANE dogfood

From: Sean Turner <[email-masked]>
Date: Tue, 21 May 2013 16:05:39 -0400

I've been informally asking around about what people might think about 
requesting that ietf.org add support for DANE.  Support isn't there yet 
in the browsers but folks have to deploy it on the server side and I 
think it might as well be us.  I know it's likely not going to be be as 
simple just asking, but I'd hear what the WG thinks about the idea.

spt

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 21 May 2013 14:08:19 -0600

On 5/21/13 2:05 PM, Sean Turner wrote:
> I've been informally asking around about what people might think
> about requesting that ietf.org add support for DANE.  Support isn't
> there yet in the browsers but folks have to deploy it on the server
> side and I think it might as well be us.  I know it's likely not
> going to be be as simple just asking, but I'd hear what the WG
> thinks about the idea.

+1 to eating our own dogfood.

In this case, what exactly does that mean? DANE support for the
website(s) (HTTPS), mailing lists (SMTP), chatrooms (XMPP), other?

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 May 2013 13:35:55 -0700

On May 21, 2013, at 1:08 PM, Peter Saint-Andre <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Say, didn't we just see two new drafts answering that question? :-)

--Paul Hoffman

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 21 May 2013 14:38:06 -0600

On 5/21/13 2:35 PM, Paul Hoffman wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>>> I've been informally asking around about what people might
>>> think about requesting that ietf.org add support for DANE.
>>> Support isn't there yet in the browsers but folks have to
>>> deploy it on the server side and I think it might as well be
>>> us.  I know it's likely not going to be be as simple just
>>> asking, but I'd hear what the WG thinks about the idea.
>> 

I didn't see that they proposed deployment scenarios for ietf.org...

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 May 2013 13:52:33 -0700

> I didn't see that they proposed deployment scenarios for ietf.org...

They explain some of the operational issues that the IETF would want to consider when making the decision to add TLSA records.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 21 May 2013 22:52:32 +0000

On Tue, May 21, 2013 at 01:52:33PM -0700, Paul Hoffman wrote:

> They explain some of the operational issues that the IETF would
> want to consider when making the decision to add TLSA records.

Thanks for championing the drafts Paul, much appreciated.

In terms of SMTP, given:

    ietf.org.               1800    IN      MX      0 mail.ietf.org.

and assuming this is a "secure" result (I am behind the wrong kind
of firewalls to check just at the moment), all the IETF would have
to do is publish:

    _25._tcp.mail.ietf.org.        IN      TLSA 3 1 1 <pkey_digest>

after first enabling STARTTLS support on the MTA:

    posttls-finger: Connected to mail.ietf.org[2001:1890:123a::1:1e]:25
    posttls-finger: < 220 ietfa.amsl.com ESMTP Postfix
    posttls-finger: > EHLO amnesiac.local
    posttls-finger: < 250-ietfa.amsl.com
    posttls-finger: < 250-PIPELINING
    posttls-finger: < 250-SIZE 67108864
    posttls-finger: < 250-ETRN
    posttls-finger: < 250-AUTH LOGIN PLAIN
    posttls-finger: < 250-AUTH=LOGIN PLAIN
    posttls-finger: < 250-ENHANCEDSTATUSCODES
    posttls-finger: < 250-8BITMIME
    posttls-finger: < 250 DSN
    posttls-finger: > QUIT
    posttls-finger: < 221 2.0.0 Bye

For some reason this MX host supports SASL (more suitable for an
MSA, where one would also want TLS for PLAIN or LOGIN), but not
TLS which is appropriate for an inbound MX.

    main.cf:
	smtpd_tls_cert_file = ${config_directory}/smtpd.pem
	smtpd_tls_security_level = may

	# Optional, but recommended: cache TLS sessions:
	scache = btree:${data_directory}/
	smtpd_tls_session_cache_database = ${scache}smtpd_scache

The cert can be self-signed.  Just a couple of minutes of admin
time and "postfix reload".

    makecert.sh:
	#! /bin/sh
        umask 077
	tmp=$(mktemp .smtpd.pem.XXXXXX)
	dst=smtpd.pem
        openssl req -new >> $tmp \
	    -newkey rsa:2048 -nodes -keyout /dev/stdout \
	    -x509 -sha1 -set_serial 1 -subj "/" -days 3650 \
	    -config <(printf "[req]\n%s\n[dn]\n[exts]\n%s\n[alts]\n%s\n" \
		    "$(printf "%s\n%s\n" \
			"distinguished_name=dn" \
			"x509_extensions=exts")" \
		    "$(printf "%s\n%s\n" \
			"extendedKeyUsage=serverAuth,clientAuth" \
			"subjectAltName=@alts" \
			)" \
		    "$(printf "DNS.1 = %s\n" $(uname -n))") &&
       mv $tmp "$dst"

To generate the digest for the DNS TLSA record:

    openssl pkey -in "$dst" -pubout |
	openssl pkey -pubin -outform DER |
	openssl dgst -sha256

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 21 May 2013 23:06:33 +0000

> 		    "$(printf "DNS.1 = %s\n" $(uname -n))") &&

For the record, the script uses bash <(command) syntax, so it should
be a /bin/bash not a /bin/sh script when the two are not the same.

-- 
	Viktor.

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Wed, 22 May 2013 05:59:54 +0100

On 21 May 2013, at 21:05, Sean Turner <[email-masked]> wrote:
> I've been informally asking around about what people might think about requesting that ietf.org add support for DANE.  Support isn't there yet in the browsers but folks have to deploy it on the server side and I think it might as well be us.  I know it's likely not going to be be as simple just asking, but I'd hear what the WG thinks about the idea.

A fantastic idea, but while 99.99% of all browsers don't yet support DANE, I think it would be imprudent to drop the CA-signed requirement at the moment.  This isn't a problem; just use the hashes for CA-signed certs in the TLSA records.

Cheers,
Sabahattin

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 22 May 2013 11:57:15 +0100

> website(s) (HTTPS), mailing lists (SMTP), chatrooms (XMPP), other?

Taking a guess, the initial thing will probably be to get the
tools/AMS folks familiar with whatever tools are out there,
then probably publish TLSA records for the web sites (while
keeping the CA certs of course) and after that we'll see. I
wouldn't be surprised if the SMTP/TLS with DANE thing was the
first one to offer benefits, but its maybe still a little
early for that just yet.

Cheers,
S.

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

---

From: Sean Turner <[email-masked]>
Date: Wed, 22 May 2013 08:08:07 -0400

> first one to offer benefits, but its maybe still a little

Yeah I was thinking website then smtp and then whatever comes next.

spt

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 22 May 2013 12:41:16 +0000

On Wed, May 22, 2013 at 11:57:15AM +0100, Stephen Farrell wrote:

> I wouldn't be surprised if the SMTP/TLS with DANE thing was the

It is early to expect "benefits", since very few clients are deployed
as yet, but not at all early to deploy, the TLSA record does no harm.
There is no downside, no existing SMTP clients refuse to deliver to
sites with unauthenticated certificates.

A Postfix production snapshot (Wietse code review complete) will
likely be available in June, at which point more people will be in
a position to deploy DANE TLSA capable SMTP clients.  They'll also
need a DNSSEC enabled local (127.0.0.1) caching DNS resolver.

So this is a good time to deploy server TLSA records:

    ; SHA256 digest of public key or full certificate.
    mail.example.com. IN TLSA 3 1 1 ...
    mail.example.com. IN TLSA 3 0 1 ...

    ; Or SHA256 of issuing trust-anchor CA public key.  With the trust-anchor
    ; issuer certificate included in the server chain file!
    ;
    mail.example.com. IN TLSA 2 1 1 ...
    mail.example.com. IN TLSA 2 0 1 ...

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 22 May 2013 12:49:39 +0000

> Yeah I was thinking website then smtp and then whatever comes next.

Based on deployment risk, perceived security benefit or gut feel?

For SMTP there is little to no risk, and few barriers to client
deployment (the Exim folks are also implementing, more to follow
I'm sure).

Also far more likely to be universally usable than with browsers,
where the existing PKI will still dominate for a long time.  At
the office I am behind an SSL MITM proxy appliance.  It will be
some time before the proxy does DANE, and the browser will not be
able to help, the proxy's fake certificates will never match DANE
records...

-- 
	Viktor.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 22 May 2013 07:29:07 -0700

Sean Turner <[email-masked]> writes:

> requesting that ietf.org add support for DANE.  Support isn't there
> yet in the browsers but folks have to deploy it on the server side and
> I think it might as well be us.  I know it's likely not going to be be
> as simple just asking, but I'd hear what the WG thinks about the idea.

Definitely a good thing to at least add the TLSA record.  I'm not sure
why anyone would object to that (unless they hate the concept of DANE
entirely so much that they'll fight anything about it, and I know there
are a few random people like that).

(and I know people using the DNSSEC-Tools' bloodhound browser would be happy)
-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

---

From: Paul Wouters <[email-masked]>
Date: Thu, 23 May 2013 00:21:02 -0400 (EDT)

>    mail.example.com. IN TLSA 2 0 1 ...

Would these be better located at _25._tcp.mail.example.com ? :)

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 May 2013 04:30:11 +0000

> Would these be better located at _25._tcp.mail.example.com ? :)

Responding as a matter of courtesy rather than necessity.  Yes, of
course!  Anyway, if anyone knows the sysadmins who operate mail.ietf.org,
please nudge them to enable STARTTLS and publish TLSA RRs.

The DNSSEC signature is already in place:

    $ drill -D -t mx ietf.org
    ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 64505
    ;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 8
    ;; QUESTION SECTION:
    ;; ietf.org.    IN      MX

    ;; ANSWER SECTION:
    ietf.org.       1800    IN      MX      0 mail.ietf.org.
    ietf.org.       1800    IN      RRSIG   MX ...copious line noise...

https://xkcd.com/1181/

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 May 2013 15:26:07 +0000

> TLS which is appropriate for an inbound MX.

FWIW, AMS (aka amsl.com) are no strangers to SMTP + STARTTLS:

    $ posttls-finger amsl.com
    posttls-finger: Connected to mail.amsl.com[64.170.98.20]:25
    posttls-finger: < 220 c8a.amsl.com ESMTP Postfix
    posttls-finger: > EHLO amnesiac.localhost
    posttls-finger: < 250-c8a.amsl.com
    posttls-finger: < 250-PIPELINING
    posttls-finger: < 250-SIZE 67108864
    posttls-finger: < 250-ETRN
    posttls-finger: < 250-STARTTLS
    posttls-finger: < 250-AUTH PLAIN LOGIN
    posttls-finger: < 250-AUTH=PLAIN LOGIN
    posttls-finger: < 250-ENHANCEDSTATUSCODES
    posttls-finger: < 250-8BITMIME
    posttls-finger: < 250 DSN
    posttls-finger: > STARTTLS
    posttls-finger: < 220 2.0.0 Ready to start TLS
    posttls-finger: mail.amsl.com[64.170.98.20]:25 CommonName smtp.amsl.com
    posttls-finger: certificate verification failed for mail.amsl.com[64.170.98.20]:25: self-signed certificate
    posttls-finger: mail.amsl.com[64.170.98.20]:25: subject_CN=smtp.amsl.com, issuer_CN=smtp.amsl.com, fingerprint=A8:39:D3:5D:90:65:96:D4:BB:DB:0A:E5:F9:C8:0E:14:99:15:7D:6C, pkey_fingerprint=0F:E2:FB:2F:A6:AA:69:3B:B6:4A:A3:40:6B:FD:2D:09:95:03:74:38
    posttls-finger: Untrusted TLS connection established to mail.amsl.com[64.170.98.20]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
    posttls-finger: > EHLO amnesiac.localhost
    posttls-finger: < 250-c8a.amsl.com
    posttls-finger: < 250-PIPELINING
    posttls-finger: < 250-SIZE 67108864
    posttls-finger: < 250-ETRN
    posttls-finger: < 250-AUTH PLAIN LOGIN
    posttls-finger: < 250-AUTH=PLAIN LOGIN
    posttls-finger: < 250-ENHANCEDSTATUSCODES
    posttls-finger: < 250-8BITMIME
    posttls-finger: < 250 DSN
    posttls-finger: > QUIT
    posttls-finger: < 221 2.0.0 Bye

-- 
	Viktor.