Subject: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

From: Warren Kumari <[email-masked]>
Date: Mon, 17 Jan 2011 15:46:10 -0500

I was hoping that would be able to stick to one open item at a time  
but the discussions on #17 (Should the first doc be TLS only or try be  
everything to everyone?) has wrapped directly to this issue, so:

I'm opening up Issue #1 (Deal with multiple TLS-based services under  
one domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1))
[ Dons frock, flaps hands, twirls the incense burner three times to  
the left,  presses button to make water squirt out of daisy add  
releases the 12 doves -- now it is official ]
-----
Description:
How to deal with multiple TLS-based services running under one domain  
name, such as a POP, IMAP, and SMTP server all running on  
mail.example.com.

Suggestions so far include:
Prefacing the host name with a service name (_pop.mail.example.com)
Prefacing the host name with a port number (_110.mail.example.com)
Returning a set of records that contain port numbers in the response.
SRV / ESRV

-----

W

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 17 Jan 2011 13:02:40 -0800

On 1/17/11 12:46 PM, Warren Kumari wrote:
> I was hoping that would be able to stick to one open item at a time but
> the discussions on #17 (Should the first doc be TLS only or try be
> I'm opening up Issue #1 (Deal with multiple TLS-based services under one
> domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1))
> [ Dons frock, flaps hands, twirls the incense burner three times to the
> left, presses button to make water squirt out of daisy add releases the
> 12 doves -- now it is official ]
> -----
> Description:
> name, such as a POP, IMAP, and SMTP server all running on mail.example.com.
>

I think SRV is an interesting approach, but simply naming the protocol 
is completely insufficient. Could someone who supports this and has 
thought about it a while give some rough text that we could consider?

As for ESRV, there has been no noticeable interest in the WGs that the 
authors have brought it to, so I think we would be impossibly premature 
to rely on it for our protocol.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Jan 2011 16:35:42 -0500 (EST)

On Mon, 17 Jan 2011, Warren Kumari wrote:

> Description:
> How to deal with multiple TLS-based services running under one domain name, 
> such as a POP, IMAP, and SMTP server all running on mail.example.com.
>

Multiple TLSA records and letting the client find the matching one from
the TLS handshake?

In other words, is there actually a problem?

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Jan 2011 16:52:12 -0500 (EST)

On Mon, 17 Jan 2011, Paul Hoffman wrote:

> I think SRV is an interesting approach, but simply naming the protocol is 
> completely insufficient. Could someone who supports this and has thought 
> about it a while give some rough text that we could consider?

It will also make it much harder to implement for the DNS administrator.

I'm not sure why this is required. If the administrator feels that they
need a separate TLSA entry, can't they just assign a different hostname
and put the certificate there? eg mail.example.com and www.example.com? or
payments.example.com?

When there are vastly different security requirements for a particular
service, they tend to be hosted on a separate server anyway, precisely
because of the different requirements (eg PCI compliance) and so they
have a different hostname and different TLSA location.

Using SRV's or _service._proto prefixes makes deployment harder in the
easy case, while using different domains for your complicated setup
only makes things harder for the harder case, and therefor to
me puts the complexity where it belongs.

And I don't think this approach "damages the internet" because of a
theoretical corner case of two widely different security levels running
on the same hostname in DNS, deploying both PKIX with CAs and DANE. I
do have an oustanding question there to Phillip to explain his use
case better, but if those cases are not forthcoming, my preference
would be to keep it simple.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 17 Jan 2011 14:23:38 -0800

> Multiple TLSA records and letting the client find the matching one from

That is another possible solution, but...

> In other words, is there actually a problem?

There is. If I trust CA1 for issuing to my mail server but not my web 
server, and CA2 for issuing to my web server but not my mail server, 
just having CA1 and CA2 in the response does not represent what I believe.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Jan 2011 18:23:28 -0500 (EST)

On Mon, 17 Jan 2011, Paul Hoffman wrote:

> There is. If I trust CA1 for issuing to my mail server but not my web server, 
> and CA2 for issuing to my web server but not my mail server, just having CA1 
> and CA2 in the response does not represent what I believe.

and using the same FQDN to access them I assume (or else there is no issue)

In that case, why not use type 1 or type 2? (eg end-user cert based TLSA instead of
CA type based)

Paul

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 18 Jan 2011 08:51:18 +0100

> Returning a set of records that contain port numbers in the response.

I would suggest adding using the SRVNames certificate extension to this 
list.  E.g. one would create multiple TLSA records, but each certificate 
would (if there's need) include SRVNames extension which would specify 
if it can be used for the protocol.  Since we honor certificate data 
(with notable exception of self-signed) that should just work[*] for 
type 1/2 certs (EE).

O.
* - I don't know if there is a support for SRVNames cert extension in 
the current implementations, since I didn't know about RFC 4985 until 
yesterday.
-- 
  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: Simon Josefsson <[email-masked]>
Date: Tue, 18 Jan 2011 14:01:09 +0100

> Returning a set of records that contain port numbers in the response.

I believe this is an important problem that must be supported.  I
brought this up earlier:

http://www.ietf.org/mail-archive/web/keyassure/current/msg00834.html

Service names are not sufficient here, since you can have a SMTP server
listening on port 25, 80, 587, 4711, 11147 etc and using the service
name would not differentiate these but that may be important.

A combination of service name and port number, like
_4711._smtp.mail.example.com, is another option and does carry more
information than only port numbers would -- however it is not clear to
me if this has any practical advantage.

Port numbers could be easier to implement -- depending on
implementations, parts of this could be done by the TLS library, and it
often does not know what kind of application protocol is running on top
of TLS.

/Simon

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 18 Jan 2011 08:01:05 -0800

On 1/18/11 5:01 AM, Simon Josefsson wrote:
> Warren Kumari<[email-masked]>  writes:
>

When you say "port numbers could be easier to implement", do you port 
numbers in "Prefacing the host name..." or "Returning a set of records..."?

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 18 Jan 2011 08:27:55 -0800

On Jan 18, 2011, at 8:01 AM, Paul Hoffman wrote:
> When you say "port numbers could be easier to implement", do you port numbers in "Prefacing the host name..." or "Returning a set of records..."?

Isn't this the whole point of SRV records?  Why shouldn't we do them, with the natural DNSSEC authenticated flow of using the SRV record(s) to find the ports, and then lookup the key(s) associated with the ports selected.

(hostname, service) -> Lookup SRV -> (hostname, port)+ -> Lookup keys by ports -> (hostname, port, key)+

Yes, this adds an additional RTT of lookup latency for the SRV lookup, but since there is a common (but not always universal) mapping of service to common ports, you could do, in parallel [1]
(host, service) -> Lookup SRV
(host, port)    -> Lookup Speculative Key

And use the speculative lookup if the SRV matches.

And its not like there are going to be many cases where a middlebox/proxy/server barfs on SRV records but allows the key-lookup records.

[1] Given how aggressively browsers prefetch A records these days, this seems like a trivial increase in overhead by comparison.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 18 Jan 2011 09:37:09 -0800

> Isn't this the whole point of SRV records?  Why shouldn't we do them, with the natural DNSSEC authenticated flow of using the SRV record(s) to find the ports, and then lookup the key(s) associated…

Yes. However, that doesn't answer the question in issue #1, which is why 
I was asking Simon (and now you) for clarification on which solution you 
prefer for the protocol.

> (host, port)    ->  Lookup Speculative Key

This sounds like you prefer "Prefacing the host name with a port number 
(_110.mail.example.com)" over "Returning a set of records that contain 
port numbers in the response", but you (and Simon) were not specific.

> And use the speculative lookup if the SRV matches.

I think this will be a likely action by applications.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 18 Jan 2011 09:57:21 -0800

On Jan 18, 2011, at 9:37 AM, Paul Hoffman wrote:

> Yes. However, that doesn't answer the question in issue #1, which is why I was asking Simon (and now you) for clarification on which solution you prefer for the protocol.
> 
> This sounds like you prefer "Prefacing the host name with a port number (_110.mail.example.com)" over "Returning a set of records that contain port numbers in the response", but you (and Simon) were not specific.

I think the answer depends on if you are using SRV or not:

So with SRV, I'd personally like the convention of

_service._transport.hostname 
_smtp._tcp.mail.example.com SRV -> 0 5 25 mail.example.com

_25._tcp.mail.example.com NEW_RR -> key material/thumbprint/certificate/whatever.

So yeah, I'd personally like a split model:

SRV is used to find the port for a service
the key record is used to find the key on a port.

Without using SRV, you'd need to have a combined record
_service._transport.hostname -> key material + port number

because otherwise, how do you know which port for which service, which is IMO, necessary to really get things to work?

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Jan 2011 19:07:37 +0100

> numbers in "Prefacing the host name..." or "Returning a set of

I mean "Prefacing the host name...".

I don't immediately see how SRV would be used here, so I don't have an
opinion on that approach.  Maybe someone could add an example, similar
to the existing examples for the other proposals, to this ticket?

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Jan 2011 19:12:22 +0100

> (hostname, service) -> Lookup SRV -> (hostname, port)+ -> Lookup keys by ports -> (hostname, port, key)+

Many applications does not work like that today.  Users are typically
asked to enter a hostname, and can provide an optional port number if
the default port number for the application protocol (e.g., 25 for smtp)
is not the intended port.

I believe DANE should be agnostic of whether SRV are used or not.  Thus
DANE could support both these look mechanisms:

1) SRV record used

2) SRV record not used

(hostname, port)+ -> Lookup keys by ports -> (hostname, port, key)+

This appears to be another argument for the option to prefix the
hostname with a port number (not service), as in:

_110.mail.example.org IN ...

/Simon

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 18 Jan 2011 14:15:40 -0500

On Tue, Jan 18, 2011 at 1:12 PM, Simon Josefsson <[email-masked]>wrote:

> > Isn't this the whole point of SRV records?  Why shouldn't we do them,
> with the natural DNSSEC authenticated flow of using the SRV record(s) to
> find the ports, and then lookup the key(s) associated with the ports
> selected.
> >
I agree.

Having the ability to declare a site wide policy is going to be totally fine
for many sites and completely meet their needs.

Other sites are going to need to have more fine control on their trust
configuration because they do things that are either more complex or involve
outsourcing or for other reasons.

I don't see any problem in having a scheme that supports more than one layer
of detail, particularly when the constraints imposed by DNS wildcards and
CNAMES are considered.

Those constraints mean that it is not possible to use prefix records in the
way that we would want to use them unless the prefix is attached to a name
that is canonical.

So any discovery scheme would have to have at least two stages:

Stage 1: Lookup the domain name without prefix, collect general records.

This stage could return a flag that says 'more detailed information
available' which would trigger a stage 2

Stage 2: Lookup protocol prefixed records for the service

This would be where SRV records would be handled and could be the place
where additional, more specific keying information is dealt with.

This could if necessary then trigger a third layer of resolution that would
be specific to the host.

Stage 3: Lookup protocol and port prefixed records for the host

Although such discovery requires three logical round trips it is entirely
feasible to elide this and combine all the round trips into one through use
of ENDS(0) extensions.

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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 18 Jan 2011 15:48:08 -0500 (EST)

> because otherwise, how do you know which port for which service, which is IMO, necessary to really get things to work?

The application that is about to do TLS knows what port the service is
running on. The only question is, should it lookup the TLSA data on
the hostname or on the <service-modifiers>.hostname.

The first will result in the app potentially looking through multiple TLSA
records before it finds a match (something it might need to support anyway)

I dont think there are that mant TLS services on a single host that this
is worth the extra complications of the service specifiers. Especially since
we're mostly talking about mail and web, and otherwise with custom apps
for TLS, the whole "service" lookup becomes tricky anyway.

Also, if in the future we want to optimise this and return these along
with A records, it would be much better if they are for the same FQDN
and not some _service._transport modifier.

So if we do modifiers, I would really want to be able to use the
non-modified method as well.

Paul

---

From: James Cloos <[email-masked]>
Date: Tue, 18 Jan 2011 16:47:15 -0500

>>>>> "WK" == Warren Kumari <[email-masked]> writes:

WK> Description:
WK> How to deal with multiple TLS-based services running under
WK> one domain name, such as a POP, IMAP, and SMTP server all
WK> running on mail.example.com.

DDDS seems to be a good fit.  Cf RFCs 3401-3404.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Warren Kumari <[email-masked]>
Date: Tue, 25 Jan 2011 14:26:00 -0500

[ Apologies to those who who may already have seen this data.]

Adam Langley (who works on Chrome) has some numbers on actual DNS  
latency as seen by users of Chrome.

-----
An experiment was conducted to help understand real world DNS latency  
and how it would affect things like TLSA....

A DNS lookup was made for RR type 13172 (taken from /dev/urandom).

This data was collected from some Chrome users who opted into  
statistics gathering.
The experiment was only enabled for Linux users and only in  
development versions of Chrome. Therefore, keep in mind that Linux  
users tend to have better network connections in general and the types  
of users who install development versions also tend to have better  
networks.

15,216 lookups were measured by 64-bit users and 9,516 by 32-bit  
users. For the 64-bit users:

51.3% of lookups finished in 0ms (i.e. a local cache, either the one  
within Chrome or a cache on the same LAN.) Afterwards, the curve  
trails off very slowly:

67.3% < 10ms
72.8% < 20ms
82% < 50ms
86.5 < 100ms
93% < 200ms
96.5 < 500ms
97.5 < 1000ms

0.56% of lookups didn't complete within 10 seconds (we don't have  
histogram buckets over 10 seconds).

For the 32-bit users the curve is similar, but shifted to the right:

68.5% < 50ms
79% < 100ms
94% < 500ms

1.4% >= 10 seconds.

------

I think that these number are really interesting, and should be kept  
in mind when we are discussing the solutions that involve multiple DNS  
round trips...

W

On Jan 17, 2011, at 3:46 PM, Warren Kumari wrote:

> but the discussions on #17 (Should the first doc be TLS only or try  
> be everything to everyone?) has wrapped directly to this issue, so:
>
> How to deal with multiple TLS-based services running under one  
> domain name, such as a POP, IMAP, and SMTP server all running on  
> mail.example.com.
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

---

From: Warren Kumari <[email-masked]>
Date: Thu, 27 Jan 2011 12:14:02 -0500

Ondrej and I would like to call #1 (and #17) soon, but would like to  
get a little clarification / restatement of folks views...

When looking up TLSA records, would folk prefer querying for:

1: Just a hostname (mail.example.com) and pick from the returned  
records.

2: Looking up a name prefixed with a port (_443.www.example.com) or  
port and proto (_443._tcp.www.example.com).
An application could optimize beyond this, but this defines what is  
required to look up.

W

On Jan 25, 2011, at 2:26 PM, Warren Kumari wrote:

> An experiment was conducted to help understand real world DNS  
> latency and how it would affect things like TLSA....
>
> users tend to have better network connections in general and the  
> types of users who install development versions also tend to have  
> better networks.
>
> in mind when we are discussing the solutions that involve multiple  
> DNS round trips...
>
> W
>
>
>> I'm opening up Issue #1 (Deal with multiple TLS-based services  
>> under one domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1) 
>> )

---

From: Paul Wouters <[email-masked]>
Date: Fri, 28 Jan 2011 00:14:51 -0500 (EST)

On Thu, 27 Jan 2011, Warren Kumari wrote:

> Ondrej and I would like to call #1 (and #17) soon, but would like to get a 
> little clarification / restatement of folks views...
>
> 1: Just a hostname (mail.example.com) and pick from the returned records.
>
> 2: Looking up a name prefixed with a port (_443.www.example.com) or port and 
> proto (_443._tcp.www.example.com).
> An application could optimize beyond this, but this defines what is required 
> to look up.

I prefer 1, because in the majority of cases there is just one certifiate,
as people tend to use different hostnames for different services
(mail.example.com, www.example.com)

In the cases people use the apex for all services, it would still likely
not exceed two TLSA records (mail/smtp/pop/imap and https)

Where people have very different security expectations per service,
they will likely even use separate physical servers neccessitating
different FQDNs.

The approach without the port and transport service modifiers are simpler and
less prone to errors.

Paul

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 28 Jan 2011 09:01:58 +0100

> (mail.example.com, www.example.com)

I disagree, it is common to have multiple services with different
certificates/key on one host -- many people access their mail server
through SMTP (port 25), submission (port 587), webmail (https) and
possibly other ways (I access e-mail over SSH which can use certificates
as well).  See my earlier post about this with real-world examples:

> The approach without the port and transport service modifiers are simpler and

It is a good way to create a lot of frustration with sysadmins.

/Simon

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 28 Jan 2011 08:27:56 -0500

It is not a question of prefer, it is a question of what you can get the DNS
infrastructure to do if you are not going to attempt to change the rules or
change DNSSEC.

DNS has wildcards and alias records (CNAME, DNAME) and they make a
difference. The short version of the story is that if you are going to
respect those constraints:

1) A prefix can only be applied to a canonical name stem

2) It has to be possible to distinguish prefixed names from wildcarded
records.

The other constraint is that early adopters of DNS keying are almost
certainly going to be completely new applications (Web Services, other new
protocols) rather than Web sites. And those new applications are likely to
specify use of an extended discovery mechanism (SRV, URI, NAPTR, etc) so
that they get fault tolerance.

If DANE wants to be relevant to early adopters that can form a critical
mass, it is probably going to have to work with the discovery mechanism used
by those Web services.

The scheme I describe in ESRV mk II combines extended discovery with
discovery of attributes relative to extended discovery (e.g. keys).

*Phase 1:*

At the start of the discovery process the query domain name is not
canonical, therefore an unprefixed query is made. So if we are looking for
the _http._tcp service, the query would be

example.com ? GSRV

As aliases must map to canonical names (no chains of aliases are allowed)
the result of this initial query will be either a canonical name or name not
found.

If you are going to make an unprefixed query in the initial case to obtain
the canonical name, you might as well put that query to work.

In many cases a site is not going to require the ability to specify service
attributes at any level of detail finer than the domain. If that is the
case, you might as well specify the information in the first phase.

In some cases a one size all solution is not going to be acceptable and the
general record will advise that additional information is available for
specific protocols (if manageably small) or should be requested in all
cases.

*Phase Two:*

In phase two we have a canonical name to query on and can use prefixes. At
this point we only have a service prefix, we do not have a host or port.

If the domain contains a wildcard record for GSRV, there is going to be a
risk of crosstalk. To avoid this we either have to be able to flag wildcard
results somehow, or we should use a different RR for prefixed results.

_http._srv.canonical.example.com ? ESRV

Again we may be able to give the data required in this instance, or phase
one may have told us to use an extended discovery mechanism such as SRV and
we may want to specify additional data that is specific to the host.

So the phase two response MAY indicate that discovery should continue to
obtain host/port specific data .

*Phase Three*

We can now obtain host specific data:

_http._srv._80.canonical.example.com ? ESRV

This design may appear somewhat heavy for web browsing. But the main
objective in the design is to support Web Services. And in Web Services we
generally care more about fault tolerance than shaving a few ms of
connection times.

To use this approach in a Web Browsing context we would want to hand the
task of performing the iterative descent to the recursive resolver so that
the results can be cached and reused.

On Thu, Jan 27, 2011 at 12:14 PM, Warren Kumari <[email-masked]> wrote:

> 2: Looking up a name prefixed with a port (_443.www.example.com) or port
> and proto (_443._tcp.www.example.com).
>> Adam Langley (who works on Chrome) has some numbers on actual DNS latency
>> as seen by users of Chrome.
>>
>> -----
>> An experiment was conducted to help understand real world DNS latency and
>> how it would affect things like TLSA....
>>
>> This data was collected from some Chrome users who opted into statistics
>> gathering.
>> The experiment was only enabled for Linux users and only in development
>> versions of Chrome. Therefore, keep in mind that Linux users tend to have
>> better network connections in general and the types of users who install
>> development versions also tend to have better networks.
>>
>> 15,216 lookups were measured by 64-bit users and 9,516 by 32-bit users.
>> For the 64-bit users:
>>
>> within Chrome or a cache on the same LAN.) Afterwards, the curve trails off
>> very slowly:
>>
>> 67.3% < 10ms
>> 72.8% < 20ms
>> 82% < 50ms
>> 86.5 < 100ms
>> 93% < 200ms
>> 96.5 < 500ms
>> 97.5 < 1000ms
>>
>> I think that these number are really interesting, and should be kept in
>> mind when we are discussing the solutions that involve multiple DNS round
>> trips...
>>
>> W
>>
>>
>>> left,  presses button to make water squirt out of daisy add releases the 12
>>> doves -- now it is official ]
>>> -----
>>> Description:

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 28 Jan 2011 15:22:21 +0100

On 28.1.2011 09:01, Simon Josefsson wrote:
> Paul Wouters<[email-masked]>  writes:
>
> as well).

Simon,

would honoring SRVNames attribute in cert (for Type 1/2) fix that?  Ie. 
have multiple records for mail.example.net, but each with different 
SRVNames attribute inside the cert?

That of course doesn't work for Type 3/4 (CA cert) and for bare keys.

Ondrej

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 28 Jan 2011 15:34:38 +0100

Ondřej Surý <[email-masked]> writes:

> would honoring SRVNames attribute in cert (for Type 1/2) fix that?
> Ie. have multiple records for mail.example.net, but each with
> different SRVNames attribute inside the cert?

Yes, although it some disadvantages.

Consider this (just an illustration, replace DANE with whatever RR name
we end up with and the hash with whatever data is needed to confirm the
certificate data, and imagine the DNSSEC records around the RRset):

mail.example.net. IN DANE 0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33
mail.example.net. IN DANE 62cdb7020ff920e5aa642c3d4066950dd1f01f4d
mail.example.net. IN DANE aef3a7835277a28da831005c2ae3b919e2076a62
mail.example.net. IN DANE 088e16a1019277b15d58faf0541e11910eb756f6

A client that wants to contact port 443 would need to establish the TLS
session and extract the peer's certificate and hash it and compare it to
all the hashes in the RR.  Only the one succeeding should be further
validated for the SubjectAltName attribute.

Compare instead the following records:

tcp_443.mail.example.net. IN DANE 0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33
tcp_25.mail.example.net. IN DANE 62cdb7020ff920e5aa642c3d4066950dd1f01f4d
tcp_587.mail.example.net. IN DANE aef3a7835277a28da831005c2ae3b919e2076a62
tcp_143.mail.example.net. IN DANE 088e16a1019277b15d58faf0541e11910eb756f6

The client connecting to mail.example.net on port 25 could look up
tcp_25.mail.example.net and directly compare that hash with the server
certificate.

Another disadvantage is that this approach requires validation of SAN's
which in turns require ASN.1 and X.509 processing.  With the my
preferred approach, to get trust in a server's certificate, all that is
needed is to hash the certificate and compare with what's in the DNS RR.

> That of course doesn't work for Type 3/4 (CA cert) and for bare keys.

Right.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 28 Jan 2011 18:22:05 +0100

> Returning a set of records that contain port numbers in the response.

Paul asked me to clarify my preference and if TLS is the only supported
protocol I prefer this approach:

_110.mail.example.com

where _110 is the port number.

If DTLS and TLS are the only supported protocols I would prefer this
approach:

tcp_110.mail.example.com (TLS)
udp_110.mail.example.com (DTLS)

/Simon

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Jan 2011 09:30:57 -0800

On 1/27/11 9:14 AM, Warren Kumari wrote:
> Ondrej and I would like to call #1 (and #17) soon, but would like to get
> a little clarification / restatement of folks views...
>

I prefer #1, but think #2 is OK. If we go with #2, I prefer that we keep 
the semantics close to SRV, and not combine port and transport type into 
a single label.

---

From: James Cloos <[email-masked]>
Date: Fri, 28 Jan 2011 13:22:48 -0500

>>>>> "WK" == Warren Kumari <[email-masked]> writes:

WK> Ondrej and I would like to call #1 (and #17) soon, but would like to
WK> get a little clarification / restatement of folks views...

WK> When looking up TLSA records, would folk prefer querying for:

WK> 1: Just a hostname (mail.example.com) and pick from the returned
WK> records.

We should recommend doing an NAPTR lookup on the hostname and using its
results to choose what A,AAAA,SRV,TLSA,etc RRs to look for.

-JimC

---

From: Lawrence Conroy <[email-masked]>
Date: Sat, 29 Jan 2011 12:03:52 +0000

> results to choose what A,AAAA,SRV,TLSA,etc RRs to look for.

To which I reply:
  If you're going to recommend NAPTR, then WHAT kind of NAPTR?
unaptr [RFC4848], snaptr [RFC3958], a new DDDS Application, ...
If you're going to hunt A/AAAA as well as SRV and others I *guess* UNAPTR.
I'm really not sure using UNAPTR is doing anyone a favour, but if you must, you need to spell it out.
all the best,
  Lawrence

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 29 Jan 2011 07:24:00 -0800

On 1/29/11 4:03 AM, Lawrence Conroy wrote:
>>>>>>> "WK" == Warren Kumari<[email-masked]>  writes:
>>

...or don't do this at all. If we want to make certificate associations 
widely deployed, requiring that it be tied to a protocol that is poorly 
understood and barely deployed seems like a bad idea.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 29 Jan 2011 11:51:48 -0500

Is NAPTR really poorly understood, or just poorly designed?

Putting REs into the DNS makes me feel really uncomfortable. Might as well
have javascript in there.

Human administrators can manage NAPTR records if they understand what they
are doing. Managing them automatically looks likely to me to be impossible.

So NAPTR can possibly be made to work as a means of achieving the original
goal of enabling resolution of URNs. It is not what I would want to use for
service discovery.

SRV and URI appear to me to be much closer to what we need here.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 29 Jan 2011 18:20:07 +0000

I think I'd go for some form of #2, done in any reasonable way.

One additional reason for that is that there could be multiple,
differently trusted, services on the same host (e.g. a web service
doing foo on port 80, with a foo-admin service on port 81 or
something). Not including the service info in the DANE protocol
somewhere could allow for foo to spoof as foo-admin in some cases.
I've no idea if there are things actually deployed like that now
but I do recall systems like that some years ago.

S.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 30 Jan 2011 11:34:57 +0200

> udp_110.mail.example.com (DTLS)

Note that TLS can be carried over SCTP as well as TCP (there's even an
Standards Track RFC about that).

Now, SCTP is not commonly used (oft-cited reason is PAT, which will
hopefully go away with IPv6).

-Ilari

---

From: Jakob Schlyter <[email-masked]>
Date: Sun, 30 Jan 2011 10:54:16 +0100

> where _110 is the port number.

If we're going to do a port selector, I'd prefer the scheme above and I believe we can omit the protocol selector and safely assume that the same key association is used for all protocols listening on a single port. 

  Jakob

---

From: Zack Weinberg <[email-masked]>
Date: Sun, 30 Jan 2011 11:30:49 -0800

On Sun, Jan 30, 2011 at 1:54 AM, Jakob Schlyter <[email-masked]> wrote:
> If we're going to do a port selector, I'd prefer the scheme above and I believe
> we can omit the protocol selector and safely assume that the same key
> association is used for all protocols listening on a single port.

(This is not a response to Jakob specifically.)

I like the idea of a port-selection prefix on the domain name.  I can
speak only to the Web perspective, but it is fairly common to run two
separate HTTP(S) servers on different ports; when this is done, the
browser treats them as disjoint security principals for most purposes,
so administrators may want to use separate certificates for them.
Thus, some means of associating two or more certs with the same domain
is desirable even if the machine is exclusively "a web server".

I prefer a port-selection prefix to returning multiple TLSA records
for a lookup on the bare domain name because that keeps DNS response
sizes down and means the client doesn't have to sort out which one it
needs.

I do not think it is useful to include the protocol in the prefix as
well as the port.  I have no opinion as to whether it is useful to
include the transport name (TCP, UDP, SCTP, etc).

I am _opposed_ to any scheme that ties deployment of TLSA to
deployment of service-discovery records; I like service discovery in
principle, but I don't want to add to the administrative burden of
deploying TLSA, especially for protocols that currently work without
service discovery, like HTTP.  (For protocols that already do use SRV
or MX or whatever, like SMTP, it is of course desirable for TLSA to
play well with those schemes, but I don't think I'm qualified to
figure out how that needs to work.)

zw

---

From: Paul Wouters <[email-masked]>
Date: Sun, 30 Jan 2011 15:40:31 -0500 (EST)

> sizes down and means the client doesn't have to sort out which one it

the client needs to understand that anyway, in case you are rolling a
cert, and you briefly have to have two TLSA records.

Paul

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 30 Jan 2011 22:08:31 +0100

> is desirable even if the machine is exclusively "a web server".

Good example.  This is even more common than my earlier examples, so I
even more strongly believe that any solution that doesn't permit
different certs on different ports/protocols won't fly.

> service discovery, like HTTP.

+1

I think tying TLSA to SRV is a good way to never see TLSA used in the
real world.

/Simon

---

From: Paul Wouters <[email-masked]>
Date: Sun, 30 Jan 2011 16:22:56 -0500 (EST)

> different certs on different ports/protocols won't fly.

Note that option 1 DOES permit different certs on different ports and
protocols. It is only the lookup that is different, and option 2 only
protects again a compromised server exchanging different security zone
certificates on the same server onto different services. I don't think
this really buys you anything on a compromised server.

Another case could be where an IP/hostname is presenting different
certs for different ports, where the ports are forwarded to separate hosts.
But again, if the portforwarded host or one of the port forwarded hosts is
compromised, I doubt this protection will buy you much. (If it would, the
attacker would block it and their own bogus cert and hope for foolush users)

Paul

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 30 Jan 2011 22:29:20 +0100

> this really buys you anything on a compromised server.

If you don't see the problem, think about this scenario -- if I have one
important service running on port 443 on, say, www.cacert.org, with the
private key safely stored on a HSM, and I also have one weak and
important web interface running on port 4711 for some monitoring
purpose, with a snake oil cert, and I create TLSA records to cover both
certificates and put them in the DNS, it means that anyone stealing the
snake oil private key can masquerade as www.cacert.org if clients only
validate the TLSA records.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 30 Jan 2011 22:32:09 +0100

> important web interface running on port 4711 for some monitoring
  ^^

That should be 'UNimportant', of course...

/Simon

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 30 Jan 2011 13:55:16 -0800

> validate the TLSA records.

Warren did a bad job of stating #1. It is not "all records are the 
same", but instead "each record says what port it is for". There is no 
difference in security properties between #1 and #2: it is all about 
preference for how the record is requested and its format. #1 has a 
simpler request (no port number) but an additional part of the response 
(includes the port number); #1 has an additional part of the request 
(includes the port number) but a simpler response (no port number). 
That's all.

---

From: Zack Weinberg <[email-masked]>
Date: Sun, 30 Jan 2011 14:57:25 -0800

> this really buys you anything on a compromised server.

Yes.  I advocate option 2 not for security reasons, but because it
will make life easier for the client (which does not have to sort
through many certs, it just has to say which one it needs) and cut
down on response size.

zw

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 31 Jan 2011 16:53:14 +0100

On 17.1.2011 21:46, Warren Kumari wrote:
> 1. Prefacing the host name with a service name (_pop.mail.example.com)
> 2. Prefacing the host name with a port number (_110.mail.example.com)
> 3. Returning a set of records that contain port numbers in the response.
> 4. SRV / ESRV

So to summary new suggestions which popped up on the list.

Combination of 1. and 2.:
5. Prefacing the host name with a service name and a port number: 
(_110._pop.mail.example.com).

6. Same as 5, but with a protocol selector:
(f.e. tcp_110._pop.mail.example.com)

And this is an idea I got while reading the archive:
7. Prefacing the host name with a service name and a port number with 
fallback on every level, ie. all those are valid and looked up and used 
in this order:
  _110._pop.mail.example.com IN TLSA
  _pop.mail.example.com IN TLSA
  mail.example.com IN TLSA

That way we can have quite good flexibility while not making things too 
complicated (ie. I am able to specify separate certificate for important 
service running on _443.http.www.example.com and having www.example.com 
IN TLSA <snake_oil_cert> for all other certificates at the host name).

8. Same as 7. but with a protocol selector

Ondrej

---

From: Paul Wouters <[email-masked]>
Date: Mon, 31 Jan 2011 11:22:37 -0500 (EST)

On Mon, 31 Jan 2011, Ondřej Surý wrote:

> fallback on every level, ie. all those are valid and looked up and used in 
> this order:
> service running on _443.http.www.example.com and having www.example.com IN 
> TLSA <snake_oil_cert> for all other certificates at the host name).

People seem to forget that at some not too far distant point in the future,
we want these records to come along with our A record lookup. Having them
not at the same RRlabel is going to make that next to impossible. The
*.foo.www.xelerance.com constructs all could signify a zone cut, so they
would all get dropped as out-of-bailiwick. Adding NSEC/NSEC3 for those
would really just move the problem of locating the right TLSA for the
right port to the issue of locating the right NSEC/NSEC3 for the lack of
a certain *._*.www.example.com record.

If you have two widely different security requirements, why are they on
the same FQDN? They can be on the same host with different FQDNs.

As previously listed examples of super secure website and snakeoil cert
for monitoring, you can simple add "monitoring.www.example.com" FQDN,
put its TLSA cert there and avoid this issue completely.

I still strongly believe in the simple TLSA case without port or protocol
specifiers and SRV like sub zones.

Paul

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 31 Jan 2011 17:29:46 +0100

> (f.e. tcp_110._pop.mail.example.com)

I dislike any solution that uses service names (the "_pop"), because I
haven't seen any explanation what purpose it would serve.  Is there a
use case for it?

> fallback on every level, ie. all those are valid and looked up and
> used in this order:
> That way we can have quite good flexibility while not making things
> too complicated (ie. I am able to specify separate certificate for
> important service running on _443.http.www.example.com and having
> www.example.com IN TLSA <snake_oil_cert> for all other certificates at
> the host name).

This adds roundtrips unless implementations do queries in parallel, and
the latter creates some extra network packets.  Network traffic is
cheap, so I kind of like it.  However I fear some implementations will
skip the (_443.www.example.com,IN,TLS) query and go directly for the
(www.example.com,IN,TLS) which kind of destroys the flexibility.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 31 Jan 2011 17:38:19 +0100

Paul Wouters <[email-masked]> writes:

> People seem to forget that at some not too far distant point in the
> future, we want these records to come along with our A record lookup.
> Having them not at the same RRlabel is going to make that next to
> impossible.

Why?

Compare how DNSSEC modified DNS to ship other records along with A
record lookups, and those records aren't always on the same RRlabel as
the query.  So I don't immediately see why it would be next to
impossible to do something similar.

/Simon

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 31 Jan 2011 11:38:46 -0500

On Mon, Jan 31, 2011 at 11:22:37AM -0500, Paul Wouters wrote:
> we want these records to come along with our A record lookup. 

I apologise for being a little (!) disengaged, but was there a plan
for getting records to "come along" with an A record lookup that did
not involve special server side processing?  Because getting things to
"come along" with A record lookups involves reformatting the Internet,
or at least the DNS, and previous efforts in that rut have not been
notable for their success.

(It is a conceivably different requirement to get the A and AAAA to
come along with a new kind of record, but it's certainly not
assignment by espert review.)

A

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

---

From: "George Barwood" <[email-masked]>
Date: Mon, 31 Jan 2011 17:14:49 -0000

>would all get dropped as out-of-bailiwick.

No - in DNS the trust is heirarchical, so the records are not out-of-bailiwick.

Besides in this context they will be signed and of course signed data can always be accepted
( after checking the signatures ) regardless of bailiwick.

There may be problems with response size though - unless TCP is used.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 31 Jan 2011 14:25:38 -0500 (EST)

On Mon, 31 Jan 2011, Andrew Sullivan wrote:

> not involve special server side processing?

Sorry, I should not have used "we" here.

There are those who believe some method of obtaining cryptographicly
relevant material along with the A/AAAA record, meta-RR or EDNS) is
extremely useful. This includes anonymized circuits, such as "tor"
that have a very latent setup cost.

> Because getting things to

I'd be interested in knowing more about these old attempts. Do you have
a good set of google keywords for me?

> assignment by espert review.)

This did not entirely parse, but I guess I would not object to getting
an A/AAAA record along with TLSA, though then we also have to look at
HASTLS, and what to do when the A/AAAA does not exist. But I guess this
is getting of-topic for the discussion of "under one domain name or not",
apart from the "it's a good and simple design that works for (AFAIK) all
cases, and will make any future changes easier".

Paul

---

From: John Gilmore <[email-masked]>
Date: Mon, 31 Jan 2011 12:05:15 -0800

> impossible to do something similar.

DNSSEC was a revision of the DNS protocols themselves.  DANE is a
revision of other protocols (like TLS or IPSEC) to use information
pulled from the DNS.

Don't forget that the DNS is the glue that binds the Internet to
humans.  Armchair protocol designers can make DNS implementations
arbitrary complicated and buggy (and there was too much of that in
DNSSEC, which is why it took a decade).  It's quite amazing that it
scaled up to still work in 2011.  Its 1983 design (RFC 881-883) by
Paul Mockapetris and Jon Postel handled hundreds -- hundreds! -- of
hostnames, replacing a flat file (the "hosts table") that was updated
weekly and distributed to every machine on the ARPAnet via FTP.  They
note:

      In the long run the Internet will become too complex and change
      too fast to keep a master table of all the hosts.  At some point
      the master table will be reduced to simply the entries for the
      domain servers for the top level domains.  By this time all normal
      translation of host names into addresses should take place by
      consulting domain servers.

DNS has managed to survive for almost 30 years, coping with the gentle
administration of SRI, the cluelessness of Network Solutions, the
avarice of SAIC, the nepotism of ICANN, and the sewage of domain
speculators.  DNSSEC severely challenged it, and we still don't know
if DNSSEC will scale up to full-Internet size while providing the high
performance and high reliability that the world is used to.  Adding
more complications risks the whole house of cards.  What DNS really
needs is a multi-decade complete redesign from the ground up.  When it
was designed, distributed databases did not exist -- because there
were no networks to distribute them on.  A new design on database
principles, without centralized control, like the routing system or
the USENET, could eliminate a bunch of parasites and power-seekers and
permit the DNS to survive for the next hundred years.

Anyone who designs a simple new protocol on the theory that we'll have
to modify the algorithms in all the DNS servers is pushing their luck.
(And vastly delaying the widespread implementation of their protocol.)
If that's what's going down in this committee, be very prepared to
justify exactly why you can't do what you need to do by just defining
a record type or two, like everybody else does.  And make sure that
the "improvement" you think you're making to the DNS is sufficiently
general that it will improve the next dozen protocols, rather than
just your own.

	John Gilmore
	(who implemented the original KEY and SIG records in BIND)

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 31 Jan 2011 15:30:17 -0500

On Mon, Jan 31, 2011 at 02:25:38PM -0500, Paul Wouters wrote:
> extremely useful.

I agree that it is extremely useful.  Unfortunately, previous efforts
to cause automatic combinations to come out of the DNS have not proven
successful.  In particular,

> a good set of google keywords for me?

the most obvious example has been the repeated attempts to get A and
AAAA records in a single query.  Rather vexingly, I can't point you to
archives any more because the person who controls the old namedroppers
archives has apparently taken them offline (or at least, had last time
I checked).

> This did not entirely parse, but I guess I would not object to getting

Sorry.  The expert review process for RRTYPE assignment explictly
excludes any special server-side processing from scope.  That will
emphatically be required any time returning one RR automatically
entails returning some other RR.

Something that is important to remember here is the effect of caches.
If you have some record (say, an A record) that could be in cache, and
then you are asked for a different RRTYPE that would entail returning
the A record at the same time, what do you do with the TTLs?  What
happens at the cache if you have the existing cached A and have to go
get something else?  

A

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

---

From: Martin Rex <[email-masked]>
Date: Tue, 1 Feb 2011 01:45:26 +0100 (MET)

> I think I'd go for some form of #2, done in any reasonable way.

I also find some form of #2 the most appealing.

-Martin