On Sun, Jun 16, 2013 at 11:03:48PM -0700, Bry8 Star wrote:
> how you can make direction easy for such vast groups of users.
A fair question.
I won't attempt to explain how to operate a DNSSEC signed zone
here, sadly this is still rather complex, since DNSSEC signed zones
need to be frequently and automatically resigned, and rotating the
KSK DS records in registries is harder still. If that's part of
your question, perhaps someone else is willing to tackle this rather
weighty topic, maybe on a DNSSEC list, if not here.
So let's assume that you've somehow crossed the hurdle of implementing
DNSSEC.
Let's also assume that you have some TLS-enabled service on TCP
port 12345 of host mumble.example.com and you want to publish DANE
TLSA records for this host.
The certificate association portion of a TLSA record contains binary
data that is usually presented in hexadecimal form for ease of
entry into zone files. The underlying binary data is either:
- A complete X.509 certificate in DER form (IN TLSA X 0 0 ...)
- A complete SPKI public-key in DER form (IN TLSA X 1 0 ...)
- A binary SHA-256 digest of one of the above (IN TLSA X Y 1 ...)
- A binary SHA-512 digest of one of the above (IN TLSA X Y 2 ...)
where "X" is the certificate usage.
When X is 0 or 2, the certificate association publishes a property
of a root or intermediate CA that (possibly through a chain of
intermediate CAs) ultimately issued the certificate of mumble.example.com.
When X is 1 or 3, the certificate association publishes a property
of the actual certificate whose public key is the public key of
mumble.example.com.
Whether you choose X = 0, 1, 2 or 3 is
- part operational considerations (who updates the DNS in your
organization, how often are server keys rotated, ...). Do
you optimize for robustness in the face of buggy client
implementations (simpler is better, and nothing is simpler
than X=3) or robustness in the face of lazy operators who
neglect to coordinate key rollover with DNS updates (X=0 or
2 requires less work for the DNS operator).
- part application considerations, is the client pre-configured with
a suitable list of trusted CAs? Does the client have a secure way
to determine the service hostname (mumble.example.com), ...
- part security considerations? Which risks do you want to mitigate?
DNSSEC zone signingkey compromises? Rogue public CAs? Server
key compromises? Do your clients consult CA revocation lists?
How often are these lists updated? How quickly can you publish
a revocation? ...
- part PKI politics. Does your organization fervently believe in either
of the two PKI models (public CAs or DANE) and distance itself from the
other?
Keep in mind that when keys change some clients will have older DNSSEC
records in their caches, so you may need to publish both the old and the
new association values when transitioning between and old and a new
certificate (be it a CA or a server certificate). DANE validation will
work provided at least association matches.
All that remains is to generate the association data. If using
OpenSSL (1.0.0 or later) with the relevant certificate in a pem
format file any given TLSA record is obtained by running something
like the attached shell script.
$ ./tlsagen cert.pem mumble.example.com:12345 3 1 1
_12345._tcp.mumble.example.com. IN TLSA 3 1 1
7602662AD394EE1C74D5926454199D3F02C352BA4073E8C87942802277C6D4AA
The shell script can be improved to detect more error conditions,
so should only be used interactively with the user paying attention
to any error messages that may indicate that the output is not
usable.
The corresponding certificate from which the above output was obtained is:
-----BEGIN CERTIFICATE-----
MIIBfDCCASKgAwIBAgIBATAKBggqhkjOPQQDAjAAMB4XDTEzMDYxNzA4MDMyNloX
DTEzMDcxNzA4MDMyNlowADBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABGa/jQyV
hYKu8iEYBuwe+3uyg7iWYNXaAEaX7TLqASVWqCYtXUrFNPVFFHQd2Fb1rLG3WzIV
J4RVvFNCyblI3nSjgYwwgYkwCQYDVR0TBAIwADAdBgNVHSUEFjAUBggrBgEFBQcD
AQYIKwYBBQUHAwIwHQYDVR0OBBYEFKGA1nZ0MpriCZlTGEap0CGlFuBcMB8GA1Ud
IwQYMBaAFKGA1nZ0MpriCZlTGEap0CGlFuBcMB0GA1UdEQQWMBSCEm11bWJsZS5l
eGFtcGxlLmNvbTAKBggqhkjOPQQDAgNIADBFAiEA2PR+JLO51F5Ehg6YQRtJJCal
yEAp3M6y5ggRJTE+ZbQCIFlFJYanOkiURTrqbYwsS/kHkJ4jbfFvY+K96UDVZcXh
-----END CERTIFICATE-----
You should be able to reproduce all the combinations (the choice
of usage has no effect on the rest of the record, but must match
the role of the selected certificate file).
$ for m in 1 2 0; do for s in 1 0; do
./tlsagen cert.pem mumble.example.com:12345 3 $s $m
done; done
_12345._tcp.mumble.example.com. IN TLSA 3 1 1
7602662AD394EE1C74D5926454199D3F02C352BA4073E8C87942802277C6D4AA
_12345._tcp.mumble.example.com. IN TLSA 3 0 1
1C9621235642558FE24EF79A154617FB134D1E0F4549DECD2FF7168463E27AB4
_12345._tcp.mumble.example.com. IN TLSA 3 1 2
D578D8B9970A0CDEE928CE306BDCBC115CBB4B36FACD370C85F1F6036FE56F44B4CCEA3FC232B3BD840A719410F4D50F33D96A2A11CBE2BE05F8846A6ECA3715
_12345._tcp.mumble.example.com. IN TLSA 3 0 2
1CD33094C61030BAD34FCAB6EBA37B225F82694A3097E2DF01E179B14079B4BD54B64B5CC8A5482037EB4A6CD9EC7173157E7F2E37896BE0414D650D3BFFA2BE
_12345._tcp.mumble.example.com. IN TLSA 3 1 0
3059301306072A8648CE3D020106082A8648CE3D0301070342000466BF8D0C958582AEF2211806EC1EFB7BB283B89660D5DA004697ED32EA012556A8262D5D4AC534F54514741DD856F5ACB1B75B3215278455BC5342C9B948DE74
_12345._tcp.mumble.example.com. IN TLSA 3 0 0
3082017C30820122A003020102020101300A06082A8648CE3D0403023000301E170D3133303631373038303332365A170D3133303731373038303332365A30003059301306072A8648CE3D020106082A8648CE3D0301070342000466BF8D0C958582AEF2211806EC1EFB7BB283B89660D5DA004697ED32EA012556A8262D5D4AC534F54514741DD856F5ACB1B75B3215278455BC5342C9B948DE74A3818C30818930090603551D1304023000301D0603551D250416301406082B0601050507030106082B06010505070302301D0603551D0E04160414A180D67674329AE20999531846A9D021A516E05C301F0603551D23041830168014A180D67674329AE20999531846A9D021A516E05C301D0603551D110416301482126D756D626C652E6578616D706C652E636F6D300A06082A8648CE3D0403020348003045022100D8F47E24B3B9D45E44860E98411B492426A5C84029DCCEB2E6081125313E65B4022059452586A73A4894453AEA6D8C2C4BF907909E236DF16F63E2BDE940D565C5E1
--
Viktor.
#! /bin/sh
error() { echo "$1" 1>&2; exit 1; }
usage() { error "Usage: $0 file.pem host[:port] usage selector mtype"; }
extract() {
case "$2" in
0) openssl x509 -in "$1" -outform DER;;
1) openssl x509 -in "$1" -noout -pubkey | openssl pkey -pubin -outform DER;;
*) error "Invalid selector: $2";;
esac
}
digest() {
case "$1" in
0) cat;;
1) openssl dgst -sha256 -binary;;
2) openssl dgst -sha512 -binary;;
*) error "Invalid matching type: $1";;
esac
}
encode() {
perl -e '
($hostport, $u, $s, $m) = @ARGV;
($host, $port) = split(":", $hostport); $port ||= 443;
$/=undef;
($a=<STDIN>) =~ s/(.)/sprintf("%02X", ord($1))/egs;
printf "_%d._tcp.%s. IN TLSA %d %d %d %s\n",
$port, $host, $u, $s, $m, $a;
' "$1" "$2" "$3" "$4"
}
if [ $# -ne 5 ]; then usage; fi; c=$1; h=$2; u=$3; s=$4; m=$5
case "$u" in [0123]) : ;; *) error "Invalid certificate usage: $u";; esac
extract "$c" "$s" | digest "$m" | encode "$h" "$u" "$s" "$m"
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
