Subject: [keyassure] key per host

From: Tony Finch <[email-masked]>
Date: Thu, 19 Aug 2010 18:01:37 +0100

Phillip Hallam-Baker <[email-masked]>
>
> We should be encouraging people to use a separate private key for each
> physical host. So we certainly should not be creating specs that make it
> hard to do that.

I think the ship has already sailed on that one. A large proportion of
deployments have some kind of load balancing router / proxy between the
actual servers and the internet, so the mapping between public service
addresses (whether names or numbers) and hosts is completely virtualized.
Also a physical host will often support many virtual hosts, whether they
are entire OS instances or just lightweight web server vhosts.

Really the key should be per service, and we should not design protocols
with any idea of a visible or externally meaningful map between services
and hosts.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: SOUTHEAST, VEERING SOUTH 5 TO 7, OCCASIONALLY GALE 8. MODERATE OR
ROUGH. RAIN THEN SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 19 Aug 2010 10:05:38 -0700

> with any idea of a visible or externally meaningful map between services

However, service should be identified by both hostname AND IP address depending on the server's preference, thus any scheme that says

_keymaterial_.host.mydomain.com as a query should also include a query for

_keymaterial_.{A/AAAA record for host.mydomain.com}, IFF the reference for _keymaterial_.host.mydomain.com says that IP should be referred OR the service was contacted based on IP rather than hostname.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 13:18:57 -0400

As long as we can have multiple keys per service, that is fine.

What I was objecting to was the idea of a single key for the Web
Service for www.example.com. That is not going to work.

Nor does it need to as the cert is passed in band in SSL (as could be
any new keying material format). So the cert can tell the relying
party where to look for the instance specific key.

It also means that we can punt on issues like key rollover and such.

At a high level, what I would like to see here is a mechanism that
allows an application to generate a key pair and request registration
in the DNS as part of the install package.

On Thu, Aug 19, 2010 at 1:01 PM, Tony Finch <[email-masked]> wrote:
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

-- 
Website: http://hallambaker.com/

---

From: Tony Finch <[email-masked]>
Date: Thu, 19 Aug 2010 18:26:57 +0100

> As long as we can have multiple keys per service, that is fine.

I can see that support for multiple key signatures might be necessary to
deal with key rollover. Are there other reasons?

> Service for www.example.com. That is not going to work.

That's how TLS currently works.

> in the DNS as part of the install package.

Dynamic DNS updates ought to be part of the solution, though I don't know
how to make it easier to manage the trust relationship (i.e. the nsupdate
keys) between the DNS admin and the app admins.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HEBRIDES: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC 6 TO GALE 8
LATER. ROUGH. SHOWERS, RAIN LATER. MODERATE OR GOOD.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 19 Aug 2010 13:30:45 -0400

> deal with key rollover. Are there other reasons?

Some names provide multiple A records for different hosts.  If these  
hosts have different private keys, they'll need to publish different  
public keys.

> That's how TLS currently works.

Not true.  In TLS connection establishment, the server only presents  
one key/cert, but different servers for the same domain can present  
different keys/certs.

> keys) between the DNS admin and the app admins.

I would say that this sort of provisioning information should be out  
of the scope of the working group.  Standard DNS provisioning  
techniques apply.

---

From: Tony Finch <[email-masked]>
Date: Thu, 19 Aug 2010 18:39:17 +0100

On Thu, 19 Aug 2010, Richard L. Barnes wrote:
>
> Not true.  In TLS connection establishment, the server only presents one
> key/cert, but different servers for the same domain can present different
> keys/certs.

Who buys multiple certificates when they only need one?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
CROMARTY FORTH TYNE: SOUTH OR SOUTHEAST, 4 OR 5, OCCASIONALLY 6, VEERING
SOUTHWEST 5 TO 7 LATER. SLIGHT OR MODERATE. SHOWERS, THEN RAIN. MODERATE OR
GOOD.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 13:51:43 -0400

People who read their terms of service?

Sent from my iPad

---

From: Tony Finch <[email-masked]>
Date: Thu, 19 Aug 2010 18:51:47 +0100

On Thu, 19 Aug 2010, Nicholas Weaver wrote:
>
> However, service should be identified by both hostname AND IP address
> depending on the server's preference, thus any scheme that says
>
> _keymaterial_.{A/AAAA record for host.mydomain.com}, IFF the reference
> for _keymaterial_.host.mydomain.com says that IP should be referred OR
> the service was contacted based on IP rather than hostname.

Could you explain why you think this is necessary? TLS doesn't currently
bind names and addresses in this way, and doing so makes services less
mobile than they could be.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Thu, 19 Aug 2010 18:55:04 +0100

> People who read their terms of service?

:-)

IME, though one might need to buy a licence to use a certificate on
multiple hosts, this does not mean one needs multiple certificates
associated with multiple private keys.

Tony.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 19 Aug 2010 12:43:44 -0700

> mobile than they could be.

But SSH might:  If you want to bind to system identity rather than hostname, that would require asking based on IP.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 19 Aug 2010 15:47:18 -0400

Depends on what you mean by "system identity", doesn't it?

I tend to take a user-centric view of this.  If I type in "ssh  
10.1.1.1", then the key should be bound to the address, but if I type  
in "ssh example.com", the key should be bound to the name -- I don't  
care what the IP address is as long as the guy at the other end has  
the right key for the domain.

This does raise an interesting question for the group, though: How do  
we want to handle "https://10.1.1.1/" and "https://[fe80::abcd: 
123]/"?  Seems like there are two basic possibilities:
1. Use the reverse DNS tree
2. Declare it out of scope because we're focused authenticating domain  
names

My slight preference is for (2).

--Richard

On Aug 19, 2010, at 3:43 PM, Nicholas Weaver wrote:

> But SSH might:  If you want to bind to system identity rather than  
> hostname, that would require asking based on IP.
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 16:11:41 -0400

First off, remember that due to a bug in the way SSL was originally
designed, we currently have to burn an IPv4 address per SSL instance.
I know that there are work-arounds, but if you start to depend on them
you make th backwards compatibility story much harder.

What we are trying to do here is to make use of crypto as easy and
painless as possible. So we should make as much effort as possible to
conform to the existing infrastructure rather than create unnecessary
restrictions.

Take for example the common case today where we have 300 web servers
on one host with one IP address. At the moment only one of those
virtual web servers can have SSL enabled since the client does not
tell the server which domain it is interested in until after the cert
is transferred.

Say that I am managing 100,000 sites on 100 actual machines. Do I want
to have to manage 100,000 keys that are bound to the sites or 100 keys
that are bound to machines? Note that the sites float fairly freely
from machine to machine and moving crypto on machines that use crypto
accelerators is non-trivial.

If the crypto keys are bound to the machine, then all I need to do to
transfer a virtual web server is to move the content and once that is
complete flip the relevant bits in the DNS to redirect queries.

When I started I was looking at three RRs to support the features I
consider necessary. But I now see that I could do it with a single
record, provided that it is extensible.

Say that a web client is trying to connect to www.example.com. Today
the resolution process begins with pulling the A record. I suggest
that instead the client should make requests for:

www.example.com           A
_http._tcp.example.com   OPTIONS

These can fire in parallel so there is no real performance hit.

The OPTIONS record is a list of ASCII encoded tag-value pairs, just
like TXT and just like DKIM uses.

The record may contain:

* key information
* security policy information
* protocol information

All the fields in the record are defined on a per-application protocol
record basis. So there would be a general draft and an application
specific draft to state how to use this record with HTTP, SMTP,
SUBMIT, IMAP, POP3 and others.

For the simplest Web site the record might be

_http._tcp.www.example.com OPTIONS "ssl=offered
certh=(sha2,0b92c7808b91f7dc1cadaf8f9afe4d9834372adcc3e18f1d
4df6704768eea870)"

For a site with two separate inbound SMTP servers we would want to
have separate keys because the failover is being run by another
company that we don't want to give a key to:

_smtp._tcp.example.com OPTIONS "ssl=offered"

cert1._smtp._tcp.example.com OPTIONS "ssl=offered
certh=(3e8e64500a2ac1ea38203ef943c5e3188e1e537076b7846219996aa225e76c0e)"
cert2._smtp._tcp.example.com OPTIONS "ssl=offered
certh=(a7fc2dcd765f94801bc06edd6420aad6cfe7fbfaa38113a5
e860a00607343b0d)"

Each cert has an X.509v3 extension inside to disambiguate it from
other certs for that service.

For the IMAP service, SSL is required rather than merely supported. So we have:

_submit._tcp.example.com OPTIONS "ssl=required SRV"
_imap._tcp.example.com OPTIONS "ssl=required SRV"
_pop._tcp.example.com OPTIONS "ssl=required SRV"

A mail client that understood this record could complete the entire
account configuration correctly from the email address, authentication
info and this record alone. And since the binding is to an SRV record
rather than to specific host names as is current practice, maintenance
of large sites is made easier.

I am not certain how SSH fits into this scheme. I typically use SSH to
log into specific machines. But since SSH can use certificates, people
could put the disambiguating blob in the cert should they need it.

This approach also opens up possibilities of specifying other protocol
enhancements. I slipped in SRV earlier, there could well be other
options.

---

From: Tony Finch <[email-masked]>
Date: Fri, 20 Aug 2010 00:31:15 +0100

On Thu, 19 Aug 2010, Nicholas Weaver wrote:
> > Could you explain why you think [keys tied to IP addresses are]
> > necessary? TLS doesn't currently bind names and addresses in this way,
> > and doing so makes services less mobile than they could be.
>

Not if hosts are mobile. With an infrastructure like Bonjour, hostnames
have a more stable relationship to host identiry than IP addresses.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HEBRIDES: EASTERLY 4 BECOMING CYCLONIC GALE 8 TO STORM 10, PERHAPS VIOLENT
STORM 11 LATER. ROUGH OR VERY ROUGH. RAIN OR SQUALLY SHOWERS. MODERATE OR
POOR.

---

From: Tony Finch <[email-masked]>
Date: Fri, 20 Aug 2010 00:41:05 +0100

> you make th backwards compatibility story much harder.

I don't do web seriously any more but I get the impression that the main
brake on SNI deployment (like many other things) is IE6.

> accelerators is non-trivial.

If the server farm acts as a single service then a single key would seem
right to me. The crypto accelerator is more likely to live on the load
balancer than the servers.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
FAIR ISLE: CYCLONIC 5 BECOMING SOUTHERLY 7 TO SEVERE GALE 9, PERHAPS STORM 10
LATER. MODERATE OR ROUGH. RAIN. MODERATE OR POOR.

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 20 Aug 2010 10:22:06 +0200

On 19.8.2010 19:30, Richard L. Barnes wrote:
> I would say that this sort of provisioning information should be out of
> the scope of the working group. Standard DNS provisioning techniques apply.

Ack.  I don't see a reason why we should do anything with DNS 
provisioning.  (If anybody is willing to write BCP, he could, but I 
don't see a reason for that.)

Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 20 Aug 2010 10:29:58 +0200

On 19.8.2010 21:47, Richard L. Barnes wrote:
> I tend to take a user-centric view of this. If I type in "ssh 10.1.1.1",
> then the key should be bound to the address, but if I type in "ssh
> example.com", the key should be bound to the name -- I don't care what
> the IP address is as long as the guy at the other end has the right key
> for the domain.
>
> This does raise an interesting question for the group, though: How do we
> want to handle "https://10.1.1.1/" and "https://[fe80::abcd:123]/"?
> Seems like there are two basic possibilities:

Because of RFC1918 addresses, I tend to prefer (2).

Ondrej

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Aug 2010 07:53:41 -0400

We definitely should not write that protocol here. Hence I wrote 'at a
high level'.

But we should not paint ourselves into a corner here and adopt
unrealistic assumptions that preclude that type of approach.

Limiting services to a single shared key is bad crypto hygiene and
harder to manage. There is no advantage to doing so.

On Fri, Aug 20, 2010 at 4:22 AM, Ondřej Surý <[email-masked]> wrote:
> Ack.  I don't see a reason why we should do anything with DNS provisioning.
>  (If anybody is willing to write BCP, he could, but I don't see a reason for
> that.)
>
> Ondrej
> --
>  Ondřej Surý

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Aug 2010 07:55:46 -0400

My preference is to rule it out of scope as well.

It is possible to use the DNS for purposes other than resolution of
names, but that does not mean it is a good idea.