Subject: [dane] Protocol / port numbers as prefix

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 16 Aug 2011 10:11:14 -0400

It is clearly causing some people discomfort to have protocols and port numbers as prefixes.  Why not just push them into the RRDATA and provision the TLSA directly under the affected name?  

On the one hand...
-- CNAME works as Phil expects it to
-- Wildcarding works cleanly

On the other hand...
-- CNAME would always allow target zone to control TLSA 
-- Easy to enumerate TLSA services on a given host 
   -> But you could do this anyway with a few extra queries
-- Large response sizes if a host has many services
   -> Still probably dominated by DNSSEC overhead

I don't really have a dog in this fight, but thought the possibility worth raising.  Thoughts?

--Richard

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 16 Aug 2011 17:26:05 +0200

> It is clearly causing some people discomfort to have protocols and port numbers as prefixes.  Why not just push them into the RRDATA and provision the TLSA directly under the affected name?  

Hi Richard,

I would like to point out that we already had this discussion (at least once):

http://trac.tools.ietf.org/wg/dane/trac/ticket/1

and here is the mail thread:

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

While I don't have a problem reopening the issue if that's what
the WG wants I would prefer to not reiterate the same issues
again and again unless you (all) at least read the mailing list
archives.

Thanks,
O.

--
 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: "Richard L. Barnes" <[email-masked]>
Date: Tue, 16 Aug 2011 11:46:19 -0400

Ah, there it is.  I was just summarizing because I hadn't found a record of this debate having happened.  Consider my comment withdrawn.

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 16 Aug 2011 16:56:21 +0100

The problem then is that DNS does not really allow for 65536 RRs in the same
node. So it does not work out the way people think.

I still think people are going to be getting rather a shock when they try to
deploy for large Web farms. Google certainly can't use this for
https://www.google.com/.

On Tue, Aug 16, 2011 at 4:46 PM, Richard L. Barnes <[email-masked]> wrote:

> Ah, there it is.  I was just summarizing because I hadn't found a record of
> this debate having happened.  Consider my comment withdrawn.
>
> --Richard
>
>
> >> It is clearly causing some people discomfort to have protocols and port
> numbers as prefixes.  Why not just push them into the RRDATA and provision
> the TLSA directly under the affected name?
> >
> >
> > Hi Richard,
> >
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 16 Aug 2011 12:01:37 -0700

> deploy for large Web farms. Google certainly can't use this for

Adam, in your opinion, and ignoring the performance concerns that led
you to write the TLSA-stapling spec, could Google deploy TLSA records
as presently specified?  If not, why not?

zw

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 16 Aug 2011 20:14:00 +0100

There are what, 10K front end Web servers on google.com? Presumably in some
sort of round-robin.

Each is going to have the same DNS name and port number. So if the records
are for EE certs that would be 10K records all with the same name and RR
type.

Under the DNSSEC design, that whole RR set has to be signed with a single
signature. Naive ways of avoiding that restriction are going to fail due to
caching constraints.

The only solution that I can see in that case is going to be to have the
TLSA record certify a cert-signing cert that signs the EE cert. Otherwise
every Web server is going to have to have the same (or one of a limited
number) SSL cert which is very bad security wise.

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 16 Aug 2011 21:27:02 +0200

On 16 aug 2011, at 21:14, Phillip Hallam-Baker wrote:

> There are what, 10K front end Web servers on google.com? Presumably in some sort of round-robin.
> 
> Each is going to have the same DNS name and port number. So if the records are for EE certs that would be 10K records all with the same name and RR type.

Why do you assume that Google would not issue all certs from a common issuer CA and put a TLSA for that?
Or just use the same keypair on all front ends? (which seems to be the case from where I'm standing)

	jakob

---

From: Adam Langley <[email-masked]>
Date: Tue, 16 Aug 2011 15:41:29 -0400

> as presently specified?  If not, why not?

I can't comment on the number of frontend servers that we have but,
from public data, you can find out that our certificates are issued
from one of three intermediates. We could publish three TLSA records
for *.google.com and cover everything that way. I don't see it being a
problem assuming that we had DNSSEC enabled.

That's on the server side. I've already discussed client-side things
in "A browser's myopic view".

Cheers

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 16 Aug 2011 16:18:15 -0400

> The problem then is that DNS does not really allow for 65536 RRs in the same node. So it does not work out the way people think.

Good point, but kind of irrelevant to this discussion unless you've got at transport protocol in mind that has more than 2**16 ports.

--Richard

> I still think people are going to be getting rather a shock when they try to deploy for large Web farms. Google certainly can't use this for https://www.google.com/.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 16 Aug 2011 22:43:50 +0100

I realized this after the initial post.

The same argument would hold for eliminating the port number, but only if
all that DANE does is publish keys. Sites that have many services could use
the same approach of advertising the key for the local CA.

The reason it would not work is that people want to do the restriction
semantics and that requires the ability to state which protocols the
restriction semantics are in use for.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 17 Aug 2011 07:59:30 -0400

Can't by spec: The "number of answer RRs" field in  DNS responses is only 16 bits wide, so there can only be 65536 RRs in the answer.

--Richard

On Aug 17, 2011, at 1:12 AM, [email-masked] wrote:

> can't by spec or implementations have set an artifical boundary?
> 
> (of course I'd not want to see the path to TCP delivery for large RRsets
> become commonplace... but does one -require- a full enumeration of all 
> ports at each RRset?)
> 
> /bill
> 
> On Tue, Aug 16, 2011 at 04:56:21PM +0100, Phillip Hallam-Baker wrote:
>>> On Aug 16, 2011, at 11:26 AM, OndEej SurC= wrote:
>>> 
>>>> OndEej SurC=
>>>> vedoucC- vC=zkumu/Head of R&D department
>>>> CZ.NIC, z.s.p.o.    --    LaboratoEe CZ.NIC

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 17 Aug 2011 19:48:14 +0100

Well we are revisiting an old point here.

But while it may be technically possible to do that, I don't think DNS works
well with 64K x 100b records = 6.4Mb

That would mean back off to TCP for a start and blow through caches.

On Wed, Aug 17, 2011 at 7:35 PM, <[email-masked]> wrote:

>  er... 16 bits sez the spec -allows- up to 65536 RR 's  in an RRset.
>  so Phillip is incorrect in his statement that "the DNS does not really
> allow for 65536 RRs in
>  the same node"  - if I parse "same node" as single RRset.
>
> /bill
>
>
> On Wed, Aug 17, 2011 at 07:59:30AM -0400, Richard L. Barnes wrote:
> > Can't by spec: The "number of answer RRs" field in  DNS responses is only
> 16 bits wide, so there can only be 65536 RRs in the answer.
> >
> > --Richard
> >
> >
> > >>> On Aug 16, 2011, at 11:26 AM, OndE ej SurC= wrote:
> > >>>
> > >>>> I would like to point out that we already had this discussion (at
> least
> > >>> once):
> > >>>>
> > >>>> OndE ej SurC=
> > >>>> CZ.NIC, z.s.p.o.    --    LaboratoE e CZ.NIC

---

From: [email-masked]
Date: Wed, 17 Aug 2011 18:35:53 +0000

er... 16 bits sez the spec -allows- up to 65536 RR 's  in an RRset.  
 so Phillip is incorrect in his statement that "the DNS does not really allow for 65536 RRs in
 the same node"  - if I parse "same node" as single RRset.

/bill

---

From: [email-masked]
Date: Wed, 17 Aug 2011 05:12:26 +0000

/bill