Subject: [keyassure] Call for consensus on #1

From: Ondřej Surý <[email-masked]>
Date: Tue, 01 Feb 2011 15:15:18 +0100

Hi,

I would like to call for consensus on issue #1.

The consensus would be that the draft-dane-protocol would define lookup 
on TLSA records as query for a name prefixed with a port or port and proto.

Possible examples (no preference here for issue #1):
  _443.www.example.com
  _443._tcp.example.com
  _tcp_443.example.com.

I will open separate issue# for the particular solution for querying 
(proto or not, fallback or not, etc.), since I don't think we have 
consensus on that yet.  (And I think we should step forward constantly 
even in small steps.)

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: Andrew Sullivan <[email-masked]>
Date: Tue, 1 Feb 2011 09:22:39 -0500

> consensus on that yet.  (And I think we should step forward constantly  

I'm not actually sure that these issues can be separated, since two of
the examples include the proto and one does not.  I prefer the 2d
arrangement, personally, because it's cleaner from the DNS point of
view.

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

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 01 Feb 2011 15:44:22 +0100

> arrangement, personally, because it's cleaner from the DNS point of

I was planning to open separate issue# on what to include into DNS name 
after we get consensus on that we want to have solution based on 
prefix+hostname in QNAME.  As opposed to just having hostname in QNAME, 
or some interaction with SRV record.  I felt that if we slowly narrow 
the topic it will not divert that much in the mailing list.

But I am fine with withdrawing the call if there is not enough support 
to go in those smaller steps.

Ondrej

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 1 Feb 2011 10:11:24 -0500

> to go in those smaller steps.

No, I have no complaint about the call, and I think it's wise to try
to separate these things for clarity.  I just meant that I don't know
they're quite as separable in fact as in principle.

A

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

---

From: Martin Rex <[email-masked]>
Date: Tue, 1 Feb 2011 16:31:12 +0100 (MET)

> Possible examples (no preference here for issue #1):

I'm confused; shouldn't this read

a   _443.www.example.com
b   _443._tcp.www.example.com
c   _tcp_443.www.example.com

What would be easier on the DNS administration (software, handling
and understanding): (b) or (c) ?

-Martin

---

From: Lawrence Conroy <[email-masked]>
Date: Tue, 1 Feb 2011 15:31:24 +0000

Hi There Ondřej, folks,
 did you mean example 3 to have no dot between the _tcp and _443 (i.e. to be one label, rather than two)?

I have no problem with example 2 (or example 1), but example 3 is confusing and/or less pleasing.

all the best,
  Lawrence

On 1 Feb 2011, at 14:15, Ondřej Surý wrote:
> The consensus would be that the draft-dane-protocol would define lookup on TLSA records as query for a name prefixed with a port or port and proto.
> 
> I will open separate issue# for the particular solution for querying (proto or not, fallback or not, etc.), since I don't think we have consensus on that yet.  (And I think we should step forward constantly even in small steps.)
> 
> Ondrej
> -- 
> Ondřej Surý
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 01 Feb 2011 16:42:26 +0100

>   did you mean example 3 to have no dot between the _tcp and _443 (i.e. to be one label, rather than two)?

Yes.

> I have no problem with example 2 (or example 1), but example 3 is confusing and/or less pleasing.

I new I shouldn't add examples there :).

 > c   _tcp_443.www.example.com

Yes, it should.

 > and understanding): (b) or (c) ?

I knew I shouldn't add the examples to my call for consensus :-).  This 
call was only about if:

a) we want to go the DNS prefix way (_prefix._hostname)
b) something else (just _hostname, SRV, etc.)

My understanding from reading the thread was that the general opinion 
(except Paul W.) was to go the DNS prefix way.

O.

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 01 Feb 2011 10:48:49 -0500

> consensus on that yet.  (And I think we should step forward constantly 

Are we going to talk about the specifics next?

I would vote for always including the transport protocol.  The client
and DNS admin both know what protocol they are using, so there is no
reason not to include it; having a fallback without the protocol is just
extra complexity.  The possibility of having two different services
using different transport protocols with the same port number seems
remote now, but we don't know what the future might hold for transport
protocols so I think we might as well do this right.

I don't feel strongly about the syntax, but I like the consistency of
_443._tcp.example.com with SRV.

-- 
Matt

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 1 Feb 2011 17:05:51 +0100

> _443._tcp.example.com with SRV.

+1

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 1 Feb 2011 11:31:58 -0500

> arrangement, personally, because it's cleaner from the DNS point of

I think that it is necessary to decide on the discovery strategy first
before deciding how to prefix labels.

There are two separate concerns here

1) How to avoid records intended only for service A being used to access
service B

2) How to discover the specific records intended for a specific instance of
service of type X on host Y on port Z.

The first is a security concern. If I have a key being advertised for a low
risk protocol (e.g. SMTP for STARTTLS), I do not want a client to accept
that for use with a high risk protocol (e.g. interbank transaction
settlements).

I think that the way to address the first concern is to use SRV prefixes but
to express them inside the certificate as use restrictions according to RFC
4985.

The second only affects some sites. Use of DNS prefix records involves
certain performance issues. Thus it is reasonable to make this an option for
those sites that require such certificates to be distinguished.

Given the limited scope of use and given that any site that has a hundred
services at the same domain label is almost certainly going to require use
of SRV or similar to make it practical, I believe that any extended
discovery mechanism for keys should map onto the prefixes used in SRV and
similar mechanisms.

There would thus be three separate phases of resolution, the first two
having the potential to trigger an additional round of resolution should it
be required.

1) Generic - all protocols and ports
   www.example.com

2) Canonical name of service prefixed by protocol
   _http._tcp.example.com

3) Canonical name of host prefixed by protocol+port
   _http._tcp._80.host1.example.com

The protocol prefixes can have an unknown number of segments. The port is a
single datum. Therefore it makes sense to prefix the port number first
before the protocol prefix.

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 1 Feb 2011 11:46:23 -0500

> (except Paul W.) was to go the DNS prefix way.

DNS Prefixes do not in general work unless the prefix is attached to a
canonical name.

If the proposal here is that the initial lookup be for a prefixed record,
there will be consequences. E.g. if the initial lookup for a key to connect
to www.example.com at port 80 is

_prefixtbs80.www.example.com

That will have the following consequences:

1) It will fail if www.example.com has a CNAME record unless there is also a
CNAME for the prefix record or the prefix is duplicated (thus losing the
point of having a CNAME.

In particular, it is no longer possible to use CNAME to direct across
administrative zones. So if we have a company that is outsourcing their mail
to mailservice.com, they cannot so so by simply adding a CNAME to their own
domain. They have to constantly monitor the destination domain to see if
there might have been key records added and create the corresponding CNAME
records.

2) DNS Wildcards do not work

If there is a wildcard record for *.example.com, there will inevitably be
cases where the resolution either cannot provide the appropriate record or
there will be ambiguity in the record delivered.

There is no DNS wildcard construct for _prefix.*.example.com.

Use of DNAME in place of CNAME does not give the desired semantics either.

One way round this problem is to require a two stage discovery process. In
the first phase the client requests the A record and the prefix record in
parallel.

Should the A record return a result telling the client that the name is not
canonical, a second query is made for the prefix at the canonical name.

If you are going to get into multi-step discovery processes, you might as
well do the job right as I propose in the other thread.

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 1 Feb 2011 20:03:08 +0100

On 1 feb 2011, at 17.31, Phillip Hallam-Baker wrote:

> The protocol prefixes can have an unknown number of segments. The port is a single datum. Therefore it makes sense to prefix the port number first before the protocol prefix.

As the port is a property of the protocol (TCP, UDP and SCTP all have ports, but that may not be true for future protocols), I'd say the protocol (if any) comes first, then any protocol specific identifier.

	jakob

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 01 Feb 2011 11:55:25 -0800

Having seen the discussion so far, I am swayed by the argument that 
proposal #1 (send all records with differentiators for ports) is 
inferior to #2 (ask for the specific record wanted) because #1 will take 
up unnecessary bandwidth. I now support #2 more than #1, and prefer 
either _portnum._transport.hostname or _portnum.hostname over 
_portnum_transport.hostname. I don't see a strong need for giving the 
transport, but it seems trivial to do and may prevent some weird problem 
in the future.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 02 Feb 2011 09:48:25 +0100

On 1.2.2011 17:31, Phillip Hallam-Baker wrote:
>
>
> On Tue, Feb 1, 2011 at 9:22 AM, Andrew Sullivan <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>      >  _443.www.example.com <http://443.www.example.com>
>      >  _443._tcp.example.com <http://tcp.example.com>
>      >  _tcp_443.example.com <http://tcp_443.example.com>.
>      >

[The following paragraph applies to everybody.]
The question was if we want to use prefix labels or not.  Could you 
please say simple 'yes', 'no' or 'undecided'?  We will decide what to 
put into the prefix label in separate ticket.

Ondřej

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 02 Feb 2011 09:58:06 +0100

> Are we going to talk about the specifics next?

Yes, as soon as we decide that we have consensus on that sublabeling is 
the way forward.

> _443._tcp.example.com with SRV.

So you agree with the proposal to use prefix labels?

Ondřej

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 02 Feb 2011 11:10:01 +0100

I prefer the _portnum._transport.hostname variant.

(My earlier answer on this was written before the decision to support
both DTLS and TLS were made, so I wanted to clarify my position.)

/Simon

---

From: Antoin Verschuren <[email-masked]>
Date: Wed, 2 Feb 2011 13:01:13 +0100

> As the port is a property of the protocol (TCP, UDP and SCTP all have ports, but that may not be true for future protocols), I'd say the protocol (if any) comes first, then any protocol specific id…

Hmm, haven't read the complete thread, but what happens if I want to run
my webserver on a different port than 443, and still want to use a
certificate for encryption ?
what do I use then, including the fact that I may be running a different
website on port 443 that I also want to publish a different certificate
for ?

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]
http://www.sidn.nl/

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 2 Feb 2011 13:15:04 +0100

> website on port 443 that I also want to publish a different certificate

You look up TLSA for _1234.tcp.www.example.com, and use the resulting association for your TLS connection. TLS itself does not care what protocol you are going to use over the resulting connection. Your client does care of course, but not for the TLSA lookup.

	jakob

-- 
Jakob Schlyter
Kirei AB - http://www.kirei.se/

---

From: Paul Wouters <[email-masked]>
Date: Wed, 2 Feb 2011 12:22:55 -0500 (EST)

> certificate for encryption ?

foo.example.com. IN TLSA x keyblobA
bar.example.com. IN TLSA y keyblobB
foo.example.com IN A 1.2.3.4
bar.example.com IN A 1.2.3.4

clean and simple. use "bar" for the service on port 443, use "foo" for the service
on the other port.

> website on port 443 that I also want to publish a different certificate

If they are different services, use a different FQDN.

Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 2 Feb 2011 13:24:05 -0500

> If they are different services, use a different FQDN.

This seems to require that the person in charge of the services is
also in charge of the naming.  In large organizations, that may not be
so.

For instance, I worked at a university where one could get a network
connection with full, unfettered access to the world.  So I could run
anything I wanted on the machine.  But there was a one-hostname:1
net[4&6]address policy.  I don't know why.  

Also, it seems to me that this reasoning is not in line with other
patterns of use of the DNS for this sort of information.  Consistency
is a good thing.

I don't feel real strongly about this, however.

A

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

---

From: Paul Wouters <[email-masked]>
Date: Wed, 2 Feb 2011 14:35:32 -0500 (EST)

> also in charge of the naming.  In large organizations, that may not be

I'd expect you would be asking the same people for a hostname that you
are going to inform to add a TLSA record? eg [email-masked].

Corner cases where one can run weird stuff on weird ports through a corporate
firewall, allowing a TLSA record but not an A record, seems well, weird :)

> patterns of use of the DNS for this sort of information.  Consistency

So is simplicity :)

I am not against any port or transport modifiers, provided we're not
dropping the simple case that will be good enough for the large majority.

Since people feel that queries should be send in parallel anyway, that
should not cause too much overhead.

So for Ondřej, I would prefer no modifiers, but could live with any of
the modifier schemes, provided we also support the non-modifier case.

Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 2 Feb 2011 15:14:07 -0500

> firewall, allowing a TLSA record but not an A record, seems well, weird :)

The problem with doing work on the INTERnet is that it has to
interoperate in all cases, not just the tidy ones.  We have a
collective history of ignoring things like NATs that need all manner
of tricks, and then later we find ourselves living with much worse
designs that happen to work well for one case.  I think we should aim
to be as broad as feasible, even at the cost of some simplicity.

> dropping the simple case that will be good enough for the large majority.

Surely you're not arguing for _two_ ways to do the same thing?  That
to me would be extremely objectionable, and actually I'd expect the
IESG to complain too.

A

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

---

From: James Cloos <[email-masked]>
Date: Wed, 02 Feb 2011 15:30:26 -0500

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

OS> The consensus would be that the draft-dane-protocol would define
OS> lookup on TLSA records as query for a name prefixed with a port or
OS> port and proto.

I've read through this entire thread and remain undecided on your (narrow)
question.

As Phillip pointed out again, using prefixes precludes CNAME and
wildcard RRs.  That strongly suggests avoiding prefixes.

But differentialtion is also necessary.

What it comes down to is the need for a discovery mechanism.  My
suggesting to use NAPTR lookups returned only negative replies.
Unfortunate, since that is the optimal solution to all of the discovery
needs discussed on this list.

That leaves two options that I can see.  The DANE RR would need to
encode the details for all possible uses at that name.

A lookup for example.com. could return an RR which says:

  *  Use cert A for traffic on tcp/sctp port 80
  *  Use cert B for traffic on tcp port 443
  *  Use cert C for traffic on tcp port 25
  *  Use cert C for traffic on tcp port 143
  *  Use cert D for traffic on tcp/sctp/udp port 5060

Or it would need to specify the zone's own root CA (by IRI and hash)
which can then specify how much trust whatever it signs should have.
The only restriction we should specify in that case is that our RR only
implies that said CA can be trusted for names which are the same as the
one where the CA pointer was found.  (For this purpose, a name such as
foo.bar.example.net. should be considered (in) a sub-zone of
example.net. only iff there is a DS RR in the trust path.  In other
words, the '.'s don't make the boundries, only DS RRs do.  We should
point that out explictly, no matter what else we do.)

If the RR we create supports either option above, then non-prefixed is
the way forward.

If, however, the consensus is against such detail, the need for both
differentiating details and also for CNAME and wildcard RRs makes it a
wash.

I just thought of another possbile wording.  We could just say that our
lookup should be for whatever the (DNS) client is already going to look
up.  If it is about to do an AorAAAA lookup on 'example.com.', then it
should also do a DANE lookup on 'example.com.'.  And if it is about to
do a SRV lookup on '_sip._tcp.example.org.' then its DANE lookup should
also be on '_sip._tcp.example.org.'. 

This got longer than I expected; I hope that all is clear....

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

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 04 Feb 2011 00:24:26 -0500

> So you agree with the proposal to use prefix labels?

Yes.  (I didn't realize you meant to solicit consensus, not just declare
it.  Maybe that helps explain my previous message.)

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 04 Feb 2011 01:00:47 -0500

On Wed, 2011-02-02 at 15:30 -0500, James Cloos wrote:
> implies that said CA can be trusted for names which are the same

"zone"?

> as the

You are right, an organization with an existing internal CA will
typically want to designate it for the entire zone, just like I want to
assert DANE exclusivity for my entire zone.  (Though they should also be
able to designate it just for the example.com host if they want.)  We
can use the same design for both kinds of zone-wide assertion.

> also be on '_sip._tcp.example.org.'. 

I prefer the design in which the DANE lookup is always on the host/port
the client will connect to and any SRV discovery is done first.  This
way, there is only one kind of DANE lookup, stunnel can do it, and if
you do load balancing with SRV, you can designate a different key for
each target server rather than pile them all at the source name.  The
one thing to watch out for is that the SRV becomes security-critical,
but I'd find it hard to argue that the current practice of issuing a
cert with the source name to the target machine is any more secure.

-- 
Matt

---

From: James Cloos <[email-masked]>
Date: Fri, 04 Feb 2011 14:36:21 -0500

After further thought, provided that Matt's proposal to deal with CNAME
and wildcard issues is used, I agree that prefixed lookups are best.

All of the arguments for prefixes are good, and his proposal deals well
with the prefix vs ( CNAME | wildcard ) issues which would otherwise
contraindicate prefixes.

-JimC

---

From: Warren Kumari <[email-masked]>
Date: Tue, 8 Feb 2011 14:46:23 -0500

Ok, we are calling consensus on #1 -- We will be using a name with a prefix....

I have just opened a new issue (Issue #19 - http://trac.tools.ietf.org/wg/dane/trac/ticket/19 ) to finalize the format of the prefix.

I realize that we have already had a fair bit of discussion on what Issue #19 discusses, and I don't want us to forget the progress that we have made on it. 
Closing #1 and opening #19 is partly an administrative move, but also allows us to focus our discussions and all understand where on the page we are...

I'd like to once again thank folk for all of their hard work and ongoing discussions.

W