On Thu, Apr 02, 2015 at 12:53:05PM +0100, Stephen Farrell wrote:
> Meta-question: was this something the wg discussed or did
> they just follow your lead?
When I joined the WG in ~Mar 15, text along these lines was already
in the Tony Finch drafts srv and smtp drafts. So I was not a party
to any WG discussion of that decision, but it is obviously the
*only* way to deal with DNSSEC redirection (be it SRV or MX).
What I was a party to was subsequent discussion of CNAME indirection
that is captured in the "ops" draft (WGLC soon, right!). I believe
we got consensus for that. And again, if the TLSA base domain is
the expanded CNAME, then that's the primary reference identifier
(used in SNI, ...) but for mixed/legacy environments the original
name is to be also be supported.
> The reason I'm asking is the obvious one - this could be
> a surprise - if the user agent for some protocol shows
> foo.example.com (or has that in a configuration) but via
> DNSSEC/DANE/SRV
You can add CNAME to the list. :-)
> we end up with a TLS session with
> bar.example.com and if we say that that is ok, then we're
> causing potential developer/deployer/user surprise, and also
> setting an upper bound for the level of TLS security that is
> only as good as domain-validated.
DANE is stronger than DV, but makes no pretense to be EV.
> That is a defensible
> position (esp for the DANE wg!) but might surprise some
> application developers etc.
I don't think there'll be many surprises, the application will
often be the one passing the reference identifiers to the TLS
library.
At least in OpenSSL (where I'm involved in designing the DANE
support) the TLS library is not going to be doing the TLSA lookups.
Rather the application will call use some DNSSEC library to obtain
the service specification records (see DANE vocabulary) and find
the associated TLSA RRs. It will then hand these (TLSA base domain,
RRs, and additional names to accept) off the the TLS library as
verification input parameters.
> One other question: you mentioned SNI below. Is that very
> relevant here, given we're not talking about the web (that
> won't use SRV) and afaik most use of SNI is for the web.
SNI is a TLS mechanism. It is not a web mechanism. Any time a
server handles multiple domains, SNI is potentially useful. We've
worked hard (in the ops draft) to make it less necessary to use
SNI, precisely by specifying that the primary reference identifier
must be the expanded name (except when CNAME expansion is not
secure).
> So, for which non-web applications is SNI sufficiently
> important to justify this (potential) level of developer
> surprise?
No surprise, on the contrary, as an SMTP developer (e.g.) I *expect*
that the reference identifer is the MX hostname, we've been waiting
for DNSSEC to make this possible for many years now. Lots of
domains have shared backup MX hosts, which can't possibly have
certificates for all the domains, but can field a certificate
for their own name.
Better yet, with DANE-EE(3) the name and expiration of the certificate
are entirely irrelevant, making multi-tenancy even easier.
[
With DANE-EE(3) Postfix will happily accept certificates in
which the Subject DN and Issuer DN are empty RDN sequences,
there are no subject alternative names (it's just a fancy key
container), and the expiration time precedes the inception
time, but I've been asked to not speak of such PKIX-violating
apostasy, and I've been good about that. :-) I'll just make
a retroactive exception for April 1 below.
]
--
Viktor.
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 12795556661879960995 (0xb192f2fd7ebcf5a3)
Signature Algorithm: sha1WithRSAEncryption
Issuer:
Validity
Not Before: Apr 2 16:46:41 2015 GMT
Not After : Apr 1 16:46:41 2015 GMT
Subject:
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c6:7c:a9:d1:67:e8:16:9e:c8:94:04:a8:8c:ca:
4f:d1:5c:d0:cf:1f:a8:6d:46:84:29:72:5d:26:fc:
e3:0d:14:08:2a:cc:27:8b:ad:ef:68:80:68:8a:b2:
be:10:df:c1:1e:26:b4:3d:94:1b:d2:2b:d8:41:05:
46:93:26:d5:f4:10:a5:48:e4:d3:ae:e1:78:34:43:
2b:13:33:3f:1a:7c:72:7f:e6:a9:24:e6:5e:c0:e6:
42:ad:d5:4e:e4:95:6c:91:b8:83:66:7e:76:6f:64:
e6:bd:c9:f1:ff:34:89:08:bc:7b:10:bf:63:a2:8c:
62:0a:0a:14:69:71:e1:24:de:e1:ce:22:2f:fe:14:
dd:cf:0d:99:b7:9e:8a:62:2d:5c:29:06:d6:7e:95:
ef:d0:8c:0f:e7:23:e8:34:2d:af:37:d6:05:bc:83:
72:00:d5:18:64:38:44:f4:61:39:9c:8b:2d:b9:b7:
04:57:16:cb:79:5a:8e:61:94:fa:2e:82:9e:0d:23:
bc:23:d8:42:01:ee:3c:53:6f:c7:13:0c:46:03:7c:
93:97:9d:50:af:af:8a:e9:e5:42:b4:46:fa:89:9c:
e9:b8:24:b9:6a:44:e9:31:50:87:1d:9f:b8:07:9a:
98:a8:0d:ca:ca:41:d3:d2:f1:d0:a5:d6:7f:76:b8:
54:7f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
B5:76:28:80:32:B8:9D:82:75:94:AE:20:9E:DF:A0:B7:BA:53:D9:55
X509v3 Authority Key Identifier:
keyid:B5:76:28:80:32:B8:9D:82:75:94:AE:20:9E:DF:A0:B7:BA:53:D9:55
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
c0:1d:17:0d:74:c0:bd:38:a1:dc:ed:b1:86:0d:81:ad:74:58:
20:c3:31:9f:80:94:4d:47:28:10:14:bf:04:30:4b:bf:dc:91:
af:d7:73:05:f4:3f:af:0f:fe:87:12:88:17:07:68:2a:51:31:
f6:b9:c6:10:3b:84:87:bd:f6:b1:dc:8d:02:e9:87:c8:cf:54:
b4:8d:bf:17:8c:e1:e1:95:4a:a8:b0:1e:75:36:e8:b5:c0:e9:
7e:52:c9:7b:62:69:55:0a:b0:0e:d6:e9:b5:a1:ea:c5:22:e1:
bc:c4:73:ec:7d:cd:26:ab:12:7a:1f:4f:7d:1d:52:25:6f:69:
f4:ea:79:91:10:68:73:a5:67:15:87:a4:e9:85:e4:1a:bd:12:
17:70:cc:83:d7:23:d8:19:79:94:38:c9:44:92:61:16:3f:e5:
07:a7:8c:6d:4e:b7:8b:d1:7f:d4:14:de:02:94:7e:2f:6f:66:
2a:04:eb:dd:2a:58:c2:bd:c7:10:e9:e7:2d:f7:18:78:4a:54:
f5:8a:75:6f:56:71:3b:be:28:07:f6:31:78:91:1c:40:0b:f8:
64:2c:ca:99:e7:da:70:25:15:be:af:77:1d:d7:2b:67:f8:01:
7c:ab:08:e8:4c:60:7c:92:d1:d1:80:14:57:bc:14:a8:10:a1:
a3:70:44:0f
-----BEGIN CERTIFICATE-----
MIIC0zCCAbugAwIBAgIJALGS8v1+vPWjMA0GCSqGSIb3DQEBBQUAMAAwHhcNMTUw
NDAyMTY0NjQxWhcNMTUwNDAxMTY0NjQxWjAAMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAxnyp0WfoFp7IlASojMpP0VzQzx+obUaEKXJdJvzjDRQIKswn
i63vaIBoirK+EN/BHia0PZQb0ivYQQVGkybV9BClSOTTruF4NEMrEzM/Gnxyf+ap
JOZewOZCrdVO5JVskbiDZn52b2Tmvcnx/zSJCLx7EL9jooxiCgoUaXHhJN7hziIv
/hTdzw2Zt56KYi1cKQbWfpXv0IwP5yPoNC2vN9YFvINyANUYZDhE9GE5nIstubcE
VxbLeVqOYZT6LoKeDSO8I9hCAe48U2/HEwxGA3yTl51Qr6+K6eVCtEb6iZzpuCS5
akTpMVCHHZ+4B5qYqA3KykHT0vHQpdZ/drhUfwIDAQABo1AwTjAdBgNVHQ4EFgQU
tXYogDK4nYJ1lK4gnt+gt7pT2VUwHwYDVR0jBBgwFoAUtXYogDK4nYJ1lK4gnt+g
t7pT2VUwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOCAQEAwB0XDXTAvTih
3O2xhg2BrXRYIMMxn4CUTUcoEBS/BDBLv9yRr9dzBfQ/rw/+hxKIFwdoKlEx9rnG
EDuEh732sdyNAumHyM9UtI2/F4zh4ZVKqLAedTbotcDpflLJe2JpVQqwDtbptaHq
xSLhvMRz7H3NJqsSeh9PfR1SJW9p9Op5kRBoc6VnFYek6YXkGr0SF3DMg9cj2Bl5
lDjJRJJhFj/lB6eMbU63i9F/1BTeApR+L29mKgTr3SpYwr3HEOnnLfcYeEpU9Yp1
b1ZxO74oB/YxeJEcQAv4ZCzKmefacCUVvq93HdcrZ/gBfKsI6ExgfJLR0YAUV7wU
qBCho3BEDw==
-----END CERTIFICATE-----
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
