Subject: [dnsext] New RRTYPE assignment request: SSLFP RRTYPE Request

From: Andrew Sullivan <[email-masked]>
Date: Mon, 13 Apr 2009 16:00:02 -0400

Dear colleagues,

I hereby post the attached template for public review, under the terms
of RFC 5395.  This posting begins the formal comment period under
section 3.1.1 (1) in RFC 5395.

Due to the unavailability of others, I'll be the expert performing
this review.

Please provide any comments you have on the proposal by 17:00 EDT on
2009-05-04.  I may not be able to consider comments received after
that time.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 13 Apr 2009 16:44:32 -0400

So, it's like this?

hostname.example.tld.            AAAA  2003:82BF:9E21::CAFE:BEEF
_http._tcp.hostname.example.tld. TLSFP 80 0 5 1 F6CD025B3F5D03040895 (
                                                 05354A0115584B56D683 )
_http._tcp.hostname.example.tld. TLSFP 80 0 5 1 584B56D683F6CD025B3F (
                                                 5D0304089505354A0115 )
_ssh._tcp.hostname.example.tld.  TLSFP 22 1 2 1 123456789abcdef67890 )
                                                 123456789abcdef67890 (
(latter instead of)
_ssh._tcp.hostname.example.tld.  SSHFP 2 1 123456789abcdef67890 )
                                            123456789abcdef67890 (

Positioning this as an improvement on the SRV record is certainly 
more promising that this old proposal to extend the KEY RR 
(http://www.potaroo.net/ietf/all-ids/draft-lewis-dnsext-key-genprot-00.txt). 
I mention the latter because it was part of the SYKED BOF, which 
tried to organize the three proposals to put application keys into 
the DNS - the SSH proposal which did make it to an RFC, a proposal 
for IPSEC which also went to RFC were the other two.  The KEY RR 
generic was dropped.

The "con" to the idea was the thought of putting too much emphasis on 
the security of DNSSEC, i.e., if the DNS key was mangled, other 
protocols could then be mangled.  I don't know if I really buy that 
argument, but it was the big hit SYKED took from the Security Area. 
But SSH and IPSECKEY (the WG name) got specific key proposals through.

I think it's a good idea, I think the discussion is over the security 
models of the applications and how much fate sharing they can take 
with DNSSEC.

At 16:00 -0400 4/13/09, Andrew Sullivan wrote:
>Attachment converted: Macintosh HD:sslfp-rr-request.txt (TEXT/ttxt) (00348806)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Getting everything you want is easy if you don't want much.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Apr 2009 14:04:59 -0700

This application is OK as it stands. I propose some changes that the proposer may or may not like. None of the proposed changes would cause the proposal to be rejected, but changing them now would mean that a later revision would not be needed.

a) The name should be something other than "TLSFP" because the RRTYPE definition is not limited to TLS. Something like "PKFP" better matches the description.

b) The description should at least mention the fact that the public key listed in the RRTYPE might not be the public key used by the responder at Service.Proto.Port.Name. That is, even if a signed record says that the public key for _pop._tcp.110.popserver.example.com is KeyA, that server might still offer KeyB in a certificate that the user would trust based on a different trust chain than the DNSSEC trust chain. This is quite an important distinction; without it, this RRTYPE description hints that *only* the named key that will be found at the given location.

--Paul Hoffman, Director
--VPN Consortium

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 13 Apr 2009 18:20:56 -0400

Dear colleagues,

Because I am addle-minded, I put the wrong requested mnemonic in the
subject line originally.  My apologies to all, and my thanks to Paul
Vixie who applied the first clue-stick.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 13 Apr 2009 18:57:35 -0400

In the same spirit of improvement as Paul's message, to provide future
flexibility, I suggest the "Mandatory" byte, which now has only two
valid byte values, be renamed "Flags" or the like with one flag bit
indicating mandatory and the other as must be set to zero and ignored
on receipt.

Thanks,
Donald

-- 
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: Florian Weimer <[email-masked]>
Date: Tue, 14 Apr 2009 21:29:57 +0200

>    E.    Description of the proposed RR type.
>
>          Here is the format of the proposed RR type:
>
>          _Service._Proto.Name TTL Class TLSFP Port Mandatory PubKeyAlgo HashAlgo FingerPrint
>
>          Service
>                 The symbolic name of the desired service as defined in
>                 [RFC2782].
>
>          Proto
>                 The symbolic name of the desired protocol as defined in
>                 [RFC2782].

What are the Service and Proto values when I enter a name in the URL
bar of a browser?  What values should be used by a
GIT/Mercurial/Subversion client?  (I'm just curious, this is not
within the scope of the RRTYPE request.)

>          PubKeyAlgo
>                 The algorithm of the public key.  This is 8 bit unsigned
>                 number.
>
>          HashAlgo
>
>                 The algorithm used to calculate fingerprint hash.  This is
>                 8 bit unsigned number.
>
>          FingerPrint
>                 The fingerprint of the public key.

>          DNS Security Registry Algorithm Numbers for PubKeyAlgo
>             http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
>          Digest Algorithms Registry for HashAlgo
>             http://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml

I'm not sure if those are a good match in general.  Even today, TLS
supports both OpenPGP RSA keys and X.509 certificates involving RSA
signatures, and you have to employ some heuristic to tell the two
apart.  So the *Algo fields suggest a level of protocol flexibility
that has to be implemented by other means anyway.

I think from a crypto POV, it might make sense for a *TLS*FP record to
specify a minimum acceptable version of TLS (to get rid of those pesky
downgrade attacks reliably).  The relevant TLS crypto algorithms
should specify a format for their fingerprints, which should be
encoded in a single octet string in the record (whether in text form
or binary, I'm not sure).

However, the proposal as-is is better than nothing.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 14 Apr 2009 17:02:41 -0400

>that has to be implemented by other means anyway.

<no-hat>

Good point I think that
TLS ClientCertificateType Identifiers Registry at
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
is more appropriate.

along with:
TLS HashAlgorithm Registry.

Reusing DNSKEY or DS registries will cause problems.

         Olafur

---

From: Peter Koch <[email-masked]>
Date: Wed, 15 Apr 2009 00:21:30 +0200

> section 3.1.1 (1) in RFC 5395.

the idea looks interesting and worth pursuing. However, I do not believe
the proposal qualifies for the simple Expert Review assignment of section
3.1.1.  More formally, the RR type assignment could be done this way, but
the proposed application of that RR type in an SRV like fashion deserves
more thought and consideration.

>    D.    Motivation for the new RRTYPE application?
> 
>          There is a need to publish a public key information in DNS, which
>          would provide sufficient trust to allow an authentication of a
>          server side public key.  There is a need to indicate that a secure
>          connection to a service is mandatory.  Data included in this new
>          RRTYPE together with the DNSSEC will create a secure chain leading
>          to establishing a secured connection from a client (such as a web
>          browser) to a server.  New RRTYPE will include a flag to indicate

This is a dangerous misconception. RRSIGs are for origin authentication only,
they do not qualify as certificates for any key material that they happen
to sign outside of DNSSEC itself.  The chain has a gap.

>          that a secure connection to a specified service is required.  Note
>          this new RRTYPE is a generic to all protocols and services.
> 

Given the far less than optimal experience with RFC 2782 and applicability
statements more guidance is needed here.  What is the querying sequence and
what does the presence or absence of a TLSFP RR indicate?  Does it parallel
an SRV or is it supposed to act as a replacement?  Which protocols are
supposed to use it in the first place?   Is the key associated with the
service or with the (server) entity delivering the service?

I'd like to encourage the proposer to describe the framework and its
interaction with SRV as well as application scenarios in more detail in
an Internet-Draft.  The "light" process is inappropriate IMHO.

-Peter

---

From: Florian Weimer <[email-masked]>
Date: Wed, 15 Apr 2009 09:32:51 +0200

> http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

Hmm.  Maybe I'm confused, but those don't seem to cover OpenPGP,
either.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 15 Apr 2009 10:14:59 +0200

On Tue, Apr 14, 2009 at 9:29 PM, Florian Weimer <[email-masked]> wrote:
> bar of a browser?

_http._tcp

> What values should be used by a GIT/Mercurial/Subversion client?

_svn._tcp
(if the service is svn and not ssh)

> (I'm just curious, this is not within the scope of the RRTYPE request.)

> that has to be implemented by other means anyway.

Just to clarify, are you speaking about 5081? So I know where to look.

> downgrade attacks reliably).

Are you sure that people will be able to distinguish between TLS 1.0,
1.1 and 1.2?

> The relevant TLS crypto algorithms should specify a format for their
> fingerprints, which should be encoded in a single octet string in
> the record (whether in text form or binary, I'm not sure).

Isn't that outside of scope of this request (and future RFC)? I'm trying to keep
this as simple as possible.

Ondrej
-- 
 Ondrej Sury
 technicky reditel/Chief Technical Officer
 -----------------------------------------
 CZ.NIC, z.s.p.o.  --  .cz domain registry
 Americka 23,120 00 Praha 2,Czech Republic
 mailto:[email-masked]  http://nic.cz/
 sip:[email-masked] tel:+420.222745110
 mob:+420.739013699     fax:+420.222745112
 -----------------------------------------

---

From: Florian Weimer <[email-masked]>
Date: Wed, 15 Apr 2009 10:37:31 +0200

> (if the service is svn and not ssh)

So I have to say beforehand which transport protocol I use?  Hmm.

> Just to clarify, are you speaking about 5081? So I know where to look.

Yes, RFC 5081.

> Are you sure that people will be able to distinguish between TLS 1.0,

I think you should do the TLSFP lookup, and if there is a minimum
version indication, specify that when you initialize the TLS
connection.  Most TLS APIs seem to include the ability.

> this as simple as possible.

It is.  The problem is that there is currently no public key
fingerprint defined by TLS, so there's more work than just creating
the record type.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 15 Apr 2009 09:50:33 -0400

>to sign outside of DNSSEC itself.  The chain has a gap.

Ah - this is the most precise and concise statement of the rationale 
why the SYKED BoF never got past round 1, why the generic key flag in 
KEY RR never became an RFC - but also captures why SSHFP and IPSECKEY 
did.

The rationale for SSH and IPSEC is that there is enough "shared fate" 
between what they are "protecting" and IP address assignment and the 
placement of address records in DNS.

I.e., in a large organization, a SysAdmin will uncrate a computer, 
load up an OS including a network stack, load a terminal app (SSH) 
and other stuff and then drop it on the desk of (say) a Web Developer 
after submitting new data for the DNS (or via DHCP, etc., etc.).  The 
security/trust gap is seen organizationally between the SysAdmin and 
the Web Developer, for one.

Returning to Peter for clarification, is the problem a lack of 
documentation of "shared fate apps" and no statement restricting the 
unfettered use of this record within that set of apps?

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 16 Apr 2009 10:41:51 +0200

> a) The name should be something other than "TLSFP" because the RRTYPE definition is not limited to TLS. Something like "PKFP" better matches the description.

I was trying to make something more focused like SSLFP is. Hence
limiting this to TLS protocol.

> b) The description should at least mention the fact that the public key listed in the RRTYPE might not be the public key used by the responder at Service.Proto.Port.Name. That is, even if a signed…

True, I'll include this in draft.

Thanks for remarks.

Ondrej.

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 16 Apr 2009 10:48:48 +0200

> to sign outside of DNSSEC itself.  The chain has a gap.

Could you please elaborate more? I am quite unsure what you have on your
mind here. What's the difference between this and SSHFP? Both are just
indications that secure communication should(must) be established with
certain public key on server side.

> an Internet-Draft.  The "light" process is inappropriate IMHO.

OK, I'll finish that I-D I started to write anyway.

Ondrej

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 16 Apr 2009 10:53:29 +0200

> So I have to say beforehand which transport protocol I use?  Hmm.

Is that a problem? Could you please provide a case which would cause
troubles with this approach?

>> Just to clarify, are you speaking about 5081? So I know where to look.

But isn't that generic and it's
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
which needs fixing?

> connection.  Most TLS APIs seem to include the ability.

I understand your point, I'll look on that. It could be specified as optional
parameter. I am afraid though that more we complicate this then less people
will be able to use it.

> fingerprint defined by TLS, so there's more work than just creating

Looks like cross-wg work to me. Argh. :)

Ondrej

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Apr 2009 07:46:46 -0700

>limiting this to TLS protocol.

I do not see where in your application it says that the key is only to be used in TLS. This is a pretty large omission. If you mean it to only be for TLS, then you need to describe the TLS modes in which it can (and cannot) be used.

I'm glad that you have said that you will now do this as a draft; it really could use input from the TLS WG.

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Koch <[email-masked]>
Date: Thu, 16 Apr 2009 20:36:55 +0200

On Thu, Apr 16, 2009 at 10:48:48AM +0200, Ond??ej Surý wrote:

> >> Data included in this new

What you'd need to achieved the described goal is a link between the key
or its fingerprint and the actual host: Some certificate that would associate
the former with the latter.

DNSSEC, by definition, only gives you the origin authentication, not data
correctness.  The latter is what you'd need to make sure that a certain
key is "rightfully" associated with a particular domain name.  Signing a zone
only means "I certify that I put _this_ into the zone.". It does not
include "... and I checked that the FP (or key) belongs to the host/entity/name".
The same property, of course, also holds for A, MX and any other normal RR type,
but nobody assumes otherwise.  The semantical gap in the chain now is exactly
between the DNSSEC signature and the binding of the key/fp to the name or
the entity behind that name.
It does not matter how large or small that gap is physically or administratively
(as in: "the same person is handling TLS certs and the DNS" or "everything
is running on the same host anyway") in a particular practical scenario.
The remaining risk might be small enough and is very likely much smaller with
DNSSEC than without, but from a security or protocol analysis point of view
you can't close it with the tools at hand.
This is not to argue against the basics of your proposal, just the claim that
there is a secure chain I consider wrong (and SSHFP is no different, for that
matter).  It's important to keep in mind the DNSSEC semantics and the
services it offers as well as those it doesn't.  Nobody should be faced with
unexpected liabilities by applying DNSSEC, or people won't deploy (or will
regret afterwards).

-Peter {hoping that this also covers Ed's question}

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 20 Apr 2009 18:18:29 -0400 (EDT)

> Reusing DNSKEY or DS registries will cause problems.

I concur with Olafur's reservations about reusing the DNSKEY and DS 
hash algorithm registries.  I'm not sure what the better replacement 
is.  (Example: do you really want to have multiple numbers assigned 
for RSA keys, as we presently do in the DNSKEY algorithm registry? 
Are there bad implications from that?  How are you handling the 
private algorithm numbers?  And will you be hitting DNSEXT up for new 
assignments in that registry when you want to publish a fingerprint 
for a key whose algorithm has yet to be defined for the purposes of 
DNSSEC?)

Furthermore, some of the details appear underspecified.  Ones that 
seem relevant to this review include: How is the fingerprint 
calculated and formatted?  (There's an implicit answer here, but it's 
only implicit.)  Which one of the eight bits in the mandatory field is 
relevant?  Lastly, the request doesn't capture the distinction between 
wire and presentation formats.  Example: How do you want that 8 bit 
number to appear in zone files?  Also underspecified, though not 
relevant for this review:  What happens if there are two records at 
the same name?  What if one has the madatory bit set and one doesn't?

As it is, this template is not ready.

-- Sam