Subject: [keyassure] Possible working group, BOF

From: Warren Kumari <[email-masked]>
Date: Thu, 2 Sep 2010 08:58:14 -0400

Hello all,

So far this has been a very active mailing list -- we have around 320 messages in around 15 days, or around 20 messages on average per day.
We have some drafts,  a defined problem, a selection of possible solutions and a large number of folk willing to work on these solutions. 

We also (surprisingly!) have a charter that most folk agree with... 

We would like to move forwards with forming a working group to try and coordinate this work, and are considering asking for a BOF in Beijing (and have already filled in the wiki at http://trac.tools.ietf.org/bof/trac/wiki/WikiStart).

Ondrej and myself believe that there is sufficient work (but a small enough amount of work that we will complete), sufficient interest, and that the work is different enough that it doesn't neatly fit into other WGs...

What are folks view on this? 

W

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 02 Sep 2010 15:40:26 +0200

> What are folks view on this? 

I agree in general, although what I believe has been missing is a
problem statement and requirements on the solution in draft form.  I
have been looking for more discussions on what should happen on the
application side (but maybe I have missed it).  I am thinking in
particular how applications will use keys stored in the DNS and what
methods are used to make sure that whatever method is used remains
secure.

/Simon

---

From: Ben Laurie <[email-masked]>
Date: Thu, 2 Sep 2010 16:07:10 +0100

On 2 September 2010 13:58, Warren Kumari <[email-masked]> wrote:

> Hello all,
>
> So far this has been a very active mailing list -- we have around 320
> messages in around 15 days, or around 20 messages on average per day.
> We have some drafts,  a defined problem, a selection of possible solutions
> and a large number of folk willing to work on these solutions.
>
> We would like to move forwards with forming a working group to try and
> coordinate this work, and are considering asking for a BOF in Beijing (and
> have already filled in the wiki at
> http://trac.tools.ietf.org/bof/trac/wiki/WikiStart).
>
> Ondrej and myself believe that there is sufficient work (but a small enough
> amount of work that we will complete), sufficient interest, and that the
> work is different enough that it doesn't neatly fit into other WGs...
>

Clearly there is work to be done, and this seems like the right place to do
it.

>
> W
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

---

From: Roy Arends <[email-masked]>
Date: Thu, 2 Sep 2010 17:16:12 +0200

> What are folks view on this? 

You have my vote!

Though I can't be in Beijing, I'm looking forward to a BOF on this. Lets settle the charter, identify work items and do some work!

Roy

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 2 Sep 2010 11:35:04 -0400

> What are folks view on this? 

I think we have a reasonably well-understood problem, people ready to
do the work, and some drafts to work on.  It's also not anyone else's
current job.  I guess a BoF is needed these days for form, but it
sure sounds like a WG to me.

A

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 02 Sep 2010 10:03:03 -0600

> sure sounds like a WG to me.

A BoF is not needed to form a WG.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Sep 2010 09:14:53 -0700

>sure sounds like a WG to me.

In fact, a BoF is *not* needed for form: that's up to the sponsoring AD. I think it is fine to go directly to WG if that's what the AD wants.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Sep 2010 09:17:29 -0700

>methods are used to make sure that whatever method is used remains

The last sentence of the proposed charter says "The group may also specify updates or clarifications to protocols to describe how protocol entities discover and validate these bindings in the execution of specific applications." Are you thinking we need something more and/or different?

--Paul Hoffman, Director
--VPN Consortium

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 2 Sep 2010 13:50:06 -0400

I would support going straight to WG.  I agree with Andrew that we  
have enough clarity to move forward.
--Richard

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 02 Sep 2010 12:06:55 -0600

On 9/2/10 11:50 AM, Richard L. Barnes wrote:
> I would support going straight to WG.  I agree with Andrew that we have
> enough clarity to move forward.

My $0.02 with no hats on...

I agree that the problem statement looks pretty good. However, this
sentence seems somewhat vague:

   The group may also specify updates or clarifications
   to protocols to describe how protocol entities discover
   and validate these bindings in the execution of specific
   applications.

IMHO it would be good to state which protocols you have in mind to
update or clarify -- leaving it open-ended might raise concerns about
possible scope creep.

I also think it would be helpful to define the deliverables, i.e., say
more about the "mechanisms for domain operators to present bindings
between names within their control and public keys" that are envisioned
by the charter.

Finally, does it make sense for the charter to mention previous work in
this area and why those older solutions are not sufficient to solve the
problem at hand?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 2 Sep 2010 15:13:36 -0400

Well one question that has not been mentioned so far is which area of
the IETF the group should be chartered in.

This looks to me to be a security problem and should be addressed in
the Security Area in my view.

The other question is phrased the wrong way in my view. The question
to ask is not whether the work should be done by this group but first
whether there is any other group where it should be done instead. I
don't think the work is appropriate for DNSEXT as it is not chartered
in the security area.

Clearly the group should work with DNSEXT and also with DKIM, TLS and
PKIX at minimum.

I would also suggest that there are clearly two phases to the work:

1) Develop an architecture for DNS based Keying

2) Describe the use of that architecture in the context of specific
applications, for example email (SMTP, POP, IMAP), Web browsing and
generalized Web Services.

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

---

From: [email-masked]
Date: Thu, 2 Sep 2010 19:31:40 +0000

for me... I think its nifty.

--bill

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Sep 2010 14:06:34 -0700

>update or clarify -- leaving it open-ended might raise concerns about

We can start with one and add more later once we are sure we know what we are doing with the one.

   The group will specify updates or extensions to HTTP
   to describe how an HTTP client that uses TLS or DTLS
   can discover and validate these bindings.
   The group may also specify updates or clarifications
   to protocols to describe how protocol entities discover
   and validate these bindings in the execution of specific
   applications.

>between names within their control and public keys" that are envisioned

I think that is premature, given that there are still differences of opinions on this list. That would be the first decision by the WG, but should be done with folks who can judge rough consensus.

>this area and why those older solutions are not sufficient to solve the

No, because we might end up saying "that old thing works just fine". Also, there is disagreement about which old work applies.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 03 Sep 2010 12:00:05 +0200

On 2.9.2010 23:06, Paul Hoffman wrote:
>> The group may also specify updates or clarifications to protocols
>> to describe how protocol entities discover and validate these
>> bindings in the execution of specific applications.
>>
>>  update or clarify -- leaving it open-ended might raise concerns
>> about possible scope creep.
>
> The group will specify updates or extensions to HTTP to describe how
> an HTTP client that uses TLS or DTLS can discover and validate these
> bindings. The group may also specify updates or clarifications to
> protocols to describe how protocol entities discover and validate
> these bindings in the execution of specific applications.

I know that HTTP is most prominent, but I would like to include SMTP,
POP3, IMAP and Jabber at least as well (to name those I am using :-)). 
Adding support for Keys in DNS is also much less controversial for those.

>> I also think it would be helpful to define the deliverables, i.e.,
>> say more about the "mechanisms for domain operators to present
>> bindings between names within their control and public keys" that
>> are envisioned by the charter.
>
> I think that is premature, given that there are still differences of
> opinions on this list. That would be the first decision by the WG,
> but should be done with folks who can judge rough consensus.
>
>> Finally, does it make sense for the charter to mention previous
>> work in this area

We could list I-Ds by Simon and Jakob and CERT RR RFC.

> and why those older solutions are not sufficient to solve the problem
> at hand?
>
> No, because we might end up saying "that old thing works just fine".
> Also, there is disagreement about which old work applies.

True.

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: Simon Josefsson <[email-masked]>
Date: Fri, 03 Sep 2010 12:39:00 +0200

Paul Hoffman <[email-masked]> writes:

> The last sentence of the proposed charter says "The group may also
> specify updates or clarifications to protocols to describe how
> protocol entities discover and validate these bindings in the
> execution of specific applications." Are you thinking we need
> something more and/or different?

The sentence is in the right direction, but it feels open-ended to me.
I'm in particular thinking it would be useful to have some more concrete
ideas on this aspect.  Your suggestion to mention some application
protocols is an improvement, as it will make us think about how the
solution will actually be used in practice.

/Simon

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 3 Sep 2010 08:26:06 -0400

The group should not be talking about extensions to HTTP to support this scheme.

It cannot possibly work as the HTTP stream is only started after the
TLS stream has either been accepted or rejected. The in-channel
upgrade of a HTTP connection does not work in this context as it
suffers from a downgrade attack vulnerability.

The place to put signaling is in either the TLS layer or the X.509
certificate by means of an extension.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 3 Sep 2010 10:21:37 -0400

I understood the proposal to basically be an update to RFC 2818  
(specifically, Section 3.1. Server Identity), which is about the name  
matching procedure and not the HTTP stream.

It is incorrect to handle this stuff at the TLS layer.  Applications  
define what sort of name authentication they require; from that  
perspective TLS is simply a vehicle for one type of credential.  What  
I would expect out of this group is a document saying "This is how you  
use a combination of <foo> from the DNS with the certificate you get  
in TLS to authenticate a remote entity in <bar> application" -- more a  
procedure for using the two protocols than a modification to either.

--Richard

On Sep 3, 2010, at 8:26 AM, Phillip Hallam-Baker wrote:

>>> say
>> I think that is premature, given that there are still differences  
>> of opinions on this list. That would be the first decision by the  
>> WG, but should be done with folks who can judge rough consensus.
>>
>>> work in
>> No, because we might end up saying "that old thing works just  
>> fine". Also, there is disagreement about which old work applies.
>>
>> --Paul Hoffman, Director
>> --VPN Consortium

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Sep 2010 00:42:20 +0100

So I've had a chance to quickly scan the plethora of
recent messages. I kind of link the idea of doing
this, but have a concern.

I don't see a queue of people saying that they'll
actually use this for something. Are there any, and
if so, what is it they want to really deploy this
for?

S.

PS: An answer of the form "you could use this for
<<foo>>" isn't what I'm after. That's as true for
this putative mechamism as it is for SPKI.

---

From: Warren Kumari <[email-masked]>
Date: Sun, 5 Sep 2010 20:03:18 -0400

> if so, what is it they want to really deploy this

Yes, I believe that this *will* be deployed and used, largely to allow A: replying parties to ensure that they have gotten the *right* CA signed cert and B: to allow the use of self-signed certs.... I think that it will also be used for other things, but I'd think that the above are the two primary use cases...

W

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 5 Sep 2010 21:42:14 -0400

I see the application area to be Web Services and other
machine-machine interactions.

The Web Browser security market is mature and it is very difficult to
see how a new entrant can gain much traction in that market. Some CAs
already offer free DV certs on a trial basis.

The Web Services market on the other hand is still wide open. The SSL
model does not seem to really be quite right there.

Another similar market is for authenticating STARTTLS in SMTP, IMAP etc.

That is why I see the need for a higher level of assurance as being possible.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Sep 2010 09:32:02 +0100

Ok, you've both said "this could be useful for TLS," which I
guess I had already realised. And I'm sure there are lots of
other things for which this could be useful. But I still haven't
seen someone say "we're very likely to use this in our product
X if its done well." I think that, or similar, would be useful.

Adding to the set of unused, or barely used, public key related
RFCs doesn't seem very attractive. (And I say that as the co-author
of some of those;-)

S.

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 6 Sep 2010 06:46:55 -0700

> RFCs doesn't seem very attractive. (And I say that as the co-author

Here's one more.  Currently DKIM provides only very minor assurance: its enough to prevent spammers but thats about it.

With cryptographically authenticated APIs (no new RRs, just APIs which can get the result of a local DNSSEC validation), DKIM becomes much more interesting.

IMO: there are already good resource records (CERT, TXT, etc) already available for cryptographic-related material.  

But there is currently no good way for an APPLICATION to know they are validated locally (on the end host system) through DNSSEC, and what's the trust chain used to validate it.

THus I believe the biggest contribution for this (possible) working group would be a nice, easy to use API: once thats in place, then DNSSEC becomes useful for who-knows-what, because it IS being deployed: it won't be some 'barely used public key related RFC', but actually something significant because DNSSEC is already being deployed and using DNSSEC in this way wouldn't increase costs.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Sep 2010 10:02:07 -0400

Another way to look at the problem is 'do we even need a working group'.

If we are building on the CERT record then all we need is to expand
the definition to include one or two new cert types:

* Fingerprint of whole cert.
* Fingerprint of a key (for schemes that use raw keys, e.g. DNSSEC).

I think that scope is pretty tight, as far as the actual scheme itself
goes it is simple enough to remove the need for an additional
algorithm field by prepending the ASN.1 OID for the corresponding hash
algorithm. That has the left hand side of the record done.

[Yes I know some people still think they can just sign the key in the
cert. But they haven't given any justification other than their gut.]

So that is the right hand side of the record done. What about a prefix
on the left to enable selection of the right CERT record when multiple
certs are in use?

Might have a bit more discussion here but its pretty simple in my
view. If you have multiple servers on a service you can have a hundred
or more certs for the same node. So a selection mechanism is essential
for scaling. There is no particular reason not to use a selection
mechanism. The obvious mechanism is the fingerprint of the cert using
the algorithm in the cert.

Then there is the final question of deployment. How does a TLS client
know that there is a DNS chain to provide assurance? I see the
following possibilities:

* Nothing - client always looks
* TLS extension (requires change to server)
* X.509 extension

Nothing is going to mean that the DNSSEC validation is only ever used
as a last resort after other means of validation have failed. I
suspect that will slow adoption.

I don't like the TLS extension as its easier to modify the cert than
the TLS stack in the server. Someone raised a doubt as to layering in
that regard.

So an X.509 extension to allow the cert to say 'hey here is my CERT
record' might be helpful. But that is something that could be proposed
in PKIX.

The reason I have been holding off submitting a draft here is not
because I don't have one. I prefer to see the arguments play out
first.

In this case I think that our approach is 80% constrained by the
legacy issues and 15% constrained by practical issues. There really
isn't a lot of scope for argument.

The only point of disagreement remaining are on the issue of prefixes
(perhaps) and hashing the full cert or just the key.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 6 Sep 2010 10:18:09 -0400

Actually, I have spoken with at least one browser vendor that is  
actively concerned with some of the "scope of authority" issues that  
this mechanism addresses (i.e., that any CA can vouch for any domain  
name right now).  So I think there is some play in the browser market  
as well.

--Richard

On Sep 5, 2010, at 9:42 PM, Phillip Hallam-Baker wrote:

>> Yes, I believe that this *will* be deployed and used, largely to  
>> allow A: replying parties to ensure that they have gotten the  
>> *right* CA signed cert and B: to allow the use of self-signed  
>> certs.... I think that it will also be used for other things, but  
>> I'd think that the above are the two primary use cases...
>>
>> W
>>
>>
>>>
>>> S.
>>>
>>>> So far this has been a very active mailing list -- we have around  
>>>> 320 messages in around 15 days, or around 20 messages on average  
>>>> per day.
>>>> We have some drafts,  a defined problem, a selection of possible  
>>>> solutions and a large number of folk willing to work on these  
>>>> solutions.
>>>>
>>>> We would like to move forwards with forming a working group to  
>>>> try and coordinate this work, and are considering asking for a  
>>>> BOF in Beijing (and have already filled in the wiki at http://trac.tools.ietf.org/bof/trac/wiki/WikiStart) 
>>>> .
>>>>
>>>> Ondrej and myself believe that there is sufficient work (but a  
>>>> small enough amount of work that we will complete), sufficient  
>>>> interest, and that the work is different enough that it doesn't  
>>>> neatly fit into other WGs...
>>>>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Sep 2010 10:40:38 -0400

Well maybe the Google people could tell us if they have their in-house
browser group on-board.

But it is still much easier to get deployment if you have an early
adopter group that is not currently catered for at all.

The killer application for the micro-computer was not word processing,
it was the spreadsheet. Word processing was a solved problem in 1980,
the typing pool did it all. It was only after every engineer had a
micro computer on their desk for doing their spreadsheets and terminal
access that they discovered it was easier to type their own memos.

On Mon, Sep 6, 2010 at 10:18 AM, Richard L. Barnes <[email-masked]> wrote:
> Actually, I have spoken with at least one browser vendor that is actively
> concerned with some of the "scope of authority" issues that this mechanism
> addresses (i.e., that any CA can vouch for any domain name right now).  So I
> think there is some play in the browser market as well.
>
> --Richard
>
>
>
>>> Yes, I believe that this *will* be deployed and used, largely to allow A:
>>> replying parties to ensure that they have gotten the *right* CA signed cert
>>> and B: to allow the use of self-signed certs.... I think that it will also
>>> be used for other things, but I'd think that the above are the two primary
>>> use cases...
>>>
>>> W
>>>
>>>
>>>>
>>>> S.
>>>>
>>>>> solutions and a large number of folk willing to work on these solutions.
>>>>>
>>>>> Ondrej and myself believe that there is sufficient work (but a small
>>>>> enough amount of work that we will complete), sufficient interest, and that
>>>>> the work is different enough that it doesn't neatly fit into other WGs...
>>>>>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Sep 2010 14:50:12 -0400

Oh, should have added that Comodo also has a browser distribution,
Comodo Dragon which is based on Chromium.

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 6 Sep 2010 21:00:37 +0200

> suspect that will slow adoption.

Why would a web browser do DNSSEC validation as a last report? I would imagine it do try DNSSEC validation first, as that would increase the speed of certificate validation and deployment.

	jakob

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 6 Sep 2010 15:11:52 -0400

Transition and interaction between validation techniques could be a  
good topic for WG discussion.

Personally, I agree with Jakob that DNSSEC-based validation should  
probably be first.  But it probably won't be the *only* validation, at  
least in the short run.  For example, in addition to verifying that  
the key/cert matches the one in the DNS, the browser could also verify  
that the cert presented is issued under a certain CA, like an EV CA.

--Richard

On Sep 6, 2010, at 3:00 PM, Jakob Schlyter wrote:

> Why would a web browser do DNSSEC validation as a last report? I  
> would imagine it do try DNSSEC validation first, as that would  
> increase the speed of certificate validation and deployment.
>
> 	jakob
>

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 6 Sep 2010 21:25:42 +0200

On 6 sep 2010, at 21.11, Richard L. Barnes wrote:

> Personally, I agree with Jakob that DNSSEC-based validation should probably be first.  But it probably won't be the *only* validation, at least in the short run.  For example, in addition to verifying that the key/cert matches the one in the DNS, the browser could also verify that the cert presented is issued under a certain CA, like an EV CA.

I believe we address this in draft-hoffman-keys-linkage-from-dns-01.txt section 2:

   o  A one-octet value, called "validation preference", specifying the
      preferences for further validation of the certificate in TLS.  A
      certificate association that contains a validation preference
      whose value is 1 indicates that the TLS administrator believes
      that it is sufficient to match the certificate association with
      the hash of certificate received in the TLS negotiation, and that
      no further certificate validation is necessary.  A certificate
      association that contains a validation preference whose value is 0
      indicates that the TLS administrator believes that it is not
      sufficient to match the certificate association with the hash of
      certificate received in the TLS negotiation, and that normal
      certificate validation is necessary.  Note that the validation
      preference is an advisory, and it is not mandatory for a TLS
      client to follow the advice.

If you have plain non-EV cert, a certificate owner would set "validation preference" to 1 and the client can just skip path validation if validation of the cert using DNSSEC succeeds.

	jakob

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 6 Sep 2010 15:34:37 -0400

That doesn't really seem like something the domain owner should be  
specifying, since it's up to the relying party to decide what  
validation he does.  If the domain owner doesn't want the RP to  
perform any X.509 path validation, then shouldn't he just present a  
self-signed cert?

--Richard

On Sep 6, 2010, at 3:25 PM, Jakob Schlyter wrote:

>> probably be first.  But it probably won't be the *only* validation,  
>> at least in the short run.  For example, in addition to verifying  
>> that the key/cert matches the one in the DNS, the browser could  
>> also verify that the cert presented is issued under a certain CA,  
>> like an EV CA.
>
> If you have plain non-EV cert, a certificate owner would set  
> "validation preference" to 1 and the client can just skip path  
> validation if validation of the cert using DNSSEC succeeds.
>
>
> 	jakob
>

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 6 Sep 2010 21:40:51 +0200

On 6 sep 2010, at 21.34, Richard L. Barnes wrote:

> That doesn't really seem like something the domain owner should be specifying, since it's up to the relying party to decide what validation he does.

The domain owner can state a preference and it is up to the relying party to decide, that's why we state that this preference is advisory.

>  If the domain owner doesn't want the RP to perform any X.509 path validation, then shouldn't he just present a self-signed cert?

As presenting a self-signed cert will, for >99% of the clients, trigger a security warning - I'm not sure that's a good transition mechanism. Telling the client that if you do DNSSEC (and we suspect you do, as you found this CERT in DNS) that's good enough is nicer and will make early adopters happier.

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Sep 2010 15:58:12 -0400

When 0% of Web Servers have this mode of authentication enabled it
would be a really weird decision for anyone to decide to slow their
application down by first attempting to validate the cert with a
method with 0% chance of success.

There is only an efficiency argument after deployment has succeeded.
And even then the chances are that DNS validation costing at least one
IP round trip will be much slower than validation using X.509 certs to
data held on the machine.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Sep 2010 16:14:43 -0400

The domain name owner can state a likelihood of support, but choice of
trust roots and/or validation means is entirely up to the relying
party.

Given that we are proposing a new scheme it seems reasonable to me to
put up a flag to say that this novel and currently fairly rare means
is available.

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 6 Sep 2010 22:16:22 +0200

> method with 0% chance of success.

Doing one DNSSEC query in parallel with your A/AAAA lookup does not slow you down that much. Also consider you do not need the result of the CERT lookup until you are half way through the TLS setup.

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Sep 2010 16:32:59 -0400

But you really don't know which cert or key you are searching for
until after the TLS session has started.

The API calls for chain validation are all hooked into TLS.
Specifically you want to be calling the DNS key assurance at the same
point that you would normally perform OCSP validation.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Sep 2010 13:51:57 -0700

>until after the TLS session has started.

This is a non-sequitur. You ask for the CERT records, and you compare them to the cert that is given in the ServerHello. This is described in detail in the draft; if it is not clear, please let us know.

>point that you would normally perform OCSP validation.

That's not what the draft says. If you have an alternate proposal, please consider writing an Internet Draft.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Sep 2010 17:29:00 -0400

Your draft only works for a limited number of certs per domain.

I don't think that is acceptable. Modern systems already have hundreds
if not thousands of servers hanging off the same domain name. And each
host should be using a separate key for hygiene reasons.

So if you are going to focus the cert retrieval mechanism you really
need to use prefixing for the reasons that have been discussed at
great length here.

The most satisfactory prefixing is one based on a hash of the cert or
a hash of the key. So you would require the cert to differentiate.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Sep 2010 14:38:53 -0700

>host should be using a separate key for hygiene reasons.

That seems implausible to me without pointers to evidence. However, your hopefully-forthcoming Internet Draft with a better idea might garner more support for your view and your proposed protocol.

>need to use prefixing for the reasons that have been discussed at

There was only slight interest in that, and more people not interested. However, your hopefully-forthcoming Internet Draft with a better idea might garner more support for your view and your proposed protocol.

>a hash of the key. So you would require the cert to differentiate.

I thought that the earlier prefixing discussion was about prefixing by service/port, not by the value of the key or the cert. I could be wrong of course, since that topic petered out fairly quickly and was not followed by any of the prefixing proponents writing an Internet Draft with a better idea that might garner more support for your view and your proposed protocol.

--Paul Hoffman, Director
--VPN Consortium

---

From: Douglas Otis <[email-masked]>
Date: Mon, 06 Sep 2010 19:13:30 -0700

> perform any X.509 path validation, then shouldn't he just present a 
Exploits that abuse a domain are often measured in hours.  When 
authorities decide that a domain's public key is being used deceptively, 
its existence in cache can easily outlive the life of such domain.  
Should there be a maximum TTL enforced for public keys and certificates 
stored in DNS?

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Sep 2010 19:42:47 -0700

At 7:13 PM -0700 9/6/10, Douglas Otis wrote:
>>That doesn't really seem like something the domain owner should be specifying, since it's up to the relying party to decide what validation he does.  If the domain owner doesn't want the RP to perform any X.509 path validation, then shouldn't he just present a self-signed cert?
>Exploits that abuse a domain are often measured in hours.  When authorities decide that a domain's public key is being used deceptively, its existence in cache can easily outlive the life of such domain.  Should there be a maximum TTL enforced for public keys and certificates stored in DNS?

<snark>
"authorities"? "decide"? "enforced"? By the Internet Police, or maybe the International Commission Of Security Experts?
</snark>

Please re-read the proposals in Internet Drafts that have been sent to this mailing list. They both say that the CERT request can return multiple records. If your domain's public key is "being used deceptively", you start using a different cert and replace the CERT record. Your supposed attack doesn't really exist, does it?

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Sep 2010 23:00:06 -0400

Or perhaps by the Security Area Directorate that is going to be
reviewing this proposal and probably taking it apart if we don't think
about issues like this one.

Revocation is a real bear in a PKI scheme. And the DNS TTL is
specified by the party controlling the domain. And on top of that we
have an expiry time on the DNSSEC signature.

You certainly can't use this mechanism (by itself) to establish more
than that your client is connecting to the controller of the DNS zone
when the sigs were created.

So the fact that someone has bought a domain name tells you nothing
about their trustworthiness so the lack of revocation probably isn't
an issue in the case of a newly created zone. Bad things can happen
through that attack but this mechanism is not designed to address that
need (but others are).

Where the problem would be worse would be in a zone-napping attack
where the black hat gets control of Twitter for eight hours and looks
to extend their control for longer.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Sep 2010 00:00:13 -0400

As I said in my earlier message, this is the one issue I consider to
be an open design question. So if we can come to consensus on it we
may not even need a WG.

By design option I mean choice of implementation. The part of the
process that is going to be much trickier is to describe precisely how
much security this scheme is providing and in particular to write the
security considerations section.

In answer to Paul's question, lets take as examples large server
installations such as Google, Gmail, CNN. In each case 100 or more
servers for one domain.

Whether or not they are using SSL at the moment is irrelevant to this
argument since the basic assumption behind this work is more crypto is
better.

Specifically, let us consider a server farm with 100 hosts serving
10,000 domain names.

The reason I chose this example is that it represents the bottom end
of the Web server market, the area where pervasive crypto needs to
reach. While it is the bottom as far as the individual Web host owner
is concerned and in terms of their costs it is actually the upper end
of the scale as far as complexity goes.

As a basic principle of cryptographic security you want your secret
information to be in as few places as possible and move as little as
possible. That is why we prefer to generate keypairs on the end entity
in a secure compartment that does not get backed up and does not
provide read access. Ideally we use trusted hardware so that the key
cannot be extracted ever.

So the simplest approach in my opinion is one key per physical host
one physical host per key so we have 100 keys to manage (plus extras
for rollover). The keys never move and we create bindings for the host
cert to the domain in the same operation as we push out the A/AAAA
records to bind the IP address. It all works fine and is simple.

Now lets consider the alternatives.

One key for all the hosts is insane. Although that is the exact model
that people are using in the bluetooth world at the moment. On
chemical plants no less. So when they lose a device for any reason
their entire network is compromised - just like using WEP security for
WiFi. Travis Goodspeed has shown how to extract keys from bluetooth
hardware devices. One master key is Very Very bad practice. Just say
no.

One key per virtual host is not quite so bad. You have the problem of
the key being potentially extracted from the virtual machine image,
you have the problem of how to move the image around securely. You
have a huge number of risk points in the system. The only advantage
over one key for all physical/virtual hosts is that a compromise may
be limited to a single host.

Note that both these important security hygiene issues are independent
of the fact that the TLS protocol does not really handle multiple
domains on one IP address until the recent versions. But this is a
significant problem with using SSL and one that we would like to be
able to address.

There are two ways in which we can handle this number of certs/cert
fingerprints.

One is to set up a CA and put the CA key in the CERT record instead of
the End Entity cert.

The second is to use prefix labels that are generated on either the
cert or the key.

The disadvantage of the first approach is that we lend up with a
complex provisioning scheme and we have to run a CA and in particular
we need to have revocation on the end entity cert. And that is the
spoiler as far as cost is concerned. It also breaks the model of using
DNSSEC for zone signing.

There is no particular disadvantage to the second approach other than
handling wildcard records is going to cost you an extra lookup. There
would have to be three new values for the CERT record:

* Hash of key
* Hash of Cert
* Pointer to a new node to get the CERT record from.

Of course the simpler approach is simply to say don't use wildcards.

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 7 Sep 2010 10:47:05 +0200

On 7 sep 2010, at 06.00, Phillip Hallam-Baker wrote:

> Specifically, let us consider a server farm with 100 hosts serving 10,000 domain names.

Are you describing how you think certificates and their keys should be deployed in such a scenario, and do you have any deployment experience in this area?

I'm asking since my experience is that what's best deployment model security-wise usually is not what's being deployed, nor what we should optimize our design for.

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Sep 2010 08:51:32 -0400

If you believe there is a conflict then suggest another use case.

I have fifteen years experience in the running of commercial CAs
services and have read RFPs from practically every type of business
that would issue one. These are entirely realistic practical
constraints.

Some of what are described as 'best security' practices are proposed
without any thought as to the practical implications. In particular
the whole concept of key rollover causes far more harm than good in
most instances.

The reason for insisting on one key per physical host, one physical
host per key  is precisely to minimize the complexity of the key
management task. It is not just a matter of better security, it
simplifies administration.

Time after time people create crypto systems with master keys and
every one of them stinks from a management point of view. Every time a
machine is compromised you have to rekey your entire system. That does
not scale.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 07 Sep 2010 10:47:12 -0700

> "authorities"? "decide"? "enforced"? By the Internet Police, or maybe the International Commission Of Security Experts?

The concern is related to a DNS resource being trusted on a basis 
similar with the information from a CA. The concern is in quickly 
eliminating threats that may otherwise continue unabated.

Cached data is limited by the protocol to 68 years.  RFC2308 indicates a 
server failure response MUST NOT be cached for more than 5 minutes.  
Enforcement police are not needed to assert a strongly worded 
recommendation.  Without a method to override cached information, 
resources that offer trust indications on par with a CA should have 
caching for the record restricted to a reasonable maximum that is likely 
to be in a range of minutes.
> Please re-read the proposals in Internet Drafts that have been sent to this mailing list. They both say that the CERT request can return multiple records. If your domain's public key is "being used…
It is not about a domain being attacked, but a domain used to attack.  
An exploit might abuse a domain, either by compromising the domain, or 
by being controlled by a bad actor.  When determined that the domain is 
being (ab)used to conduct criminal activity, domain names may be removed 
at the behest of authorities.  Even so, problems can continue beyond 
removal when malicious activity remains functional through resources 
served out of caching resolvers.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Tue, 07 Sep 2010 11:15:22 -0700

On 9/6/10 2:38 PM, Paul Hoffman wrote:

>  On 9/6/10 5:29 PM, Phillip Hallam-Baker wrote:

> > Modern systems already have hundreds if not thousands of servers
> > hanging off the same domain name. And each host should be using a
> > separate key for hygiene reasons.
 >
>  That seems implausible to me without pointers to evidence. However,
>  your hopefully-forthcoming Internet Draft with a better idea might
>  garner more support for your view and your proposed protocol.

There is a similar problem related to multiple domains referencing the 
same resources. This could be done using various aliasing techniques, or 
through separately registered domains having synchronized content, or a 
combination of both. There is no practical way to locate all possible 
aliases within a single node of the primary domain.  However, a hashed 
label scheme could offer confirmation of primary domain pointers offered 
by aliased domains.

The suggestion was to adopt a primary domain resource in the aliasing 
domain, confirmed using hash labels in the primary domain.  These hash 
labels extend the scalability limits normally reached in a one-to-many 
domain issue.  In this way, both alias agility and resource scalability 
might leverage the same mechanism.

-Doug

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 07 Sep 2010 22:13:53 +0200

> * Fingerprint of a key (for schemes that use raw keys, e.g. DNSSEC).

Just a minor point, but I believe there is value in fingerprinting the
entire certificate chain too.  That can be done by fingerprinting the
TLS Certificate structure.  It allows recipients to learn intermediate
certificates, and trust that they were the intended intermediate
certificates.

/Simon

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 7 Sep 2010 21:49:09 -0400

What's the use case for that?  The domain operator trusts the server  
enough to give him the right to speak for the domain, by vouching for  
the server's key/cert in the DNS. But he doesn't trust the server to  
present the correct cert chain?  Or he's worried about some malicious  
CA being inserted somewhere in the chain so that more people trust the  
*correct* certificate?  What's the attack scenario here?

---

From: [email-masked]
Date: Wed, 8 Sep 2010 06:44:36 +0000

> Doing one DNSSEC query in parallel with your A/AAAA lookup does not slow you down that much. Also consider you do not need the result of the CERT lookup until you are half way through the TLS setup.

	the query- sure.  the valdation may take a few more cycles.

--bill

---

From: Tony Finch <[email-masked]>
Date: Wed, 8 Sep 2010 07:54:07 +0100

> already offer free DV certs on a trial basis.

Dealing with CAs is an annoying chore. It will be easier to put a self-signed cert in the DNS.

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/

---

From: Tony Finch <[email-masked]>
Date: Wed, 8 Sep 2010 08:14:40 +0100

> Exploits that abuse a domain are often measured in hours.  When authorities decide that a domain's public key is being used deceptively, its existence in cache can easily outlive the life of such d…

No, but it can be a recommendation. There's also OCSP.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Wed, 8 Sep 2010 09:06:00 +0100

> the whole concept of key rollover causes far more harm than good in

I think this is because most protocols don't support it well. For example, x.509 doesn't allow you to authenticate a cert with its predecessor. Also, limited cert lifetimes force you to roll them every year or two.

> simplifies administration.

This is exactly backwards. It is much simpler to keep all hosts identical when they are part of a cluster providing a service. It is completely impractical to waste time dealing with a CA when spinning up new hardware.

I note that IME although CAs like you to pay per server, they don't insist on a different certificate per server.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Wed, 8 Sep 2010 09:23:28 +0100

> One is to set up a CA and put the CA key in the CERT record instead of

I quite like the idea of allowing DNSSEC to authenticate any cert in the chain, not just the leaf one.

> spoiler as far as cost is concerned.

On the other hand it simplifies DNS administration since you can publish the same CERT RR for all your services.

> It also breaks the model of using
> DNSSEC for zone signing.

Er what? How?

> handling wildcard records is going to cost you an extra lookup. 

The main disadvantage I can see is the added difficulty of getting the right stuff into the DNS, and dealing with the churn if you have many certs or keys.

Tony.

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 8 Sep 2010 11:01:15 +0200

> I quite like the idea of allowing DNSSEC to authenticate any cert in the chain, not just the leaf one.

the downside is that your then way into path validation, something I think we should try to avoid if possible.

I used to believe in this idea though; http://stupid.domain.name/ietf/draft-schlyter-pkix-dns-02.txt.

	jakob

---

From: Ben Laurie <[email-masked]>
Date: Wed, 8 Sep 2010 10:54:00 +0100

On 8 September 2010 09:06, Tony Finch <[email-masked]> wrote:

> For example, x.509 doesn't allow you to authenticate a cert with its
> predecessor.
>

Yeah. We should fix that.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 08:13:01 -0400

> Dealing with CAs is an annoying chore. It will be easier to put a self-signed cert in the DNS.

That is a very poor argument from a deployment standpoint.

In the first place you need to compare like with like. DNSSEC without
CA services is not going to provide any more than a DV level of
assurance and that already requires practically no effort. The hassle
factor comes in with OV and EV certs where the validation process is
designed to establish accountability.

As the Iridium satellite phone people discovered, it is really hard to
compete with an incumbent infrastructure as they have more resources
to bring to bear.and they can and will react to new competition.

In this case the difficulty of dealing with even the most unfriendly
of CAs is going to be nothing compared to the difficulty of running
DNSSEC in-house using first generation admin tools.

And that is before taking account of the fact that there is only one
browser provider here at the moment (two if you include both
distributions of Chromium). It is going to be a very long time before
95% of deployed browsers support any scheme developed here.

Of course we can follow the usual route of ignoring the fact that
deployment is much harder than writing specs and write yet another RFC
that never goes anywhere. I prefer to look at the situation
realistically and look for early adopter markets that can support
killer apps like Web services and mail server connections.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 09:40:48 -0400

You do it your way if you want to.

Just don't insist on designing the protocol so that the only way that
it is possible to use the spec is known to be bad security practice
when there is absolutely no need to do so.

I suspect that the reason for your difficulty here is that you are not
using state-of-the art hardware that allows trustworthy components to
be used for key storage. In that configuration your software image is
identical across all the machines as the keys are stored in the
hardware, not the software.

On Wed, Sep 8, 2010 at 4:06 AM, Tony Finch <[email-masked]> wrote:
> I think this is because most protocols don't support it well. For example,
> x.509 doesn't allow you to authenticate a cert with its predecessor. Also,
> limited cert lifetimes force you to roll them every year or two.
>
> This is exactly backwards. It is much simpler to keep all hosts identical
> when they are part of a cluster providing a service. It is completely
> impractical to waste time dealing with a CA when spinning up new hardware.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 8 Sep 2010 14:43:13 +0100

> hardware, not the software.

Suppose I think my machine is trustworthy?

> > I note that IME although CAs like you to pay per server, they don't
> insist
> > on a different certificate per server.
> > Tony.
> > --

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 09:56:18 -0400

Your machine is certainly trustED (by you)

If it allows the authentication keys to float off round the net then
it probably should not be considered especially trustWORTHY.

The standard for trustworthy is still not entirely objective, but it
is not entirely subjective either. If you want me to outsource my data
center operations to you then you need to be able to explain why your
system is trustworthy, quite likely to an auditor.

Since in your case the system is spread over more data centers than
you even know exist, you are only going to be able to say that it is
trustworthy if you can limit the number of concerns to a very simple
proposition such as 'keys are generated in the machine and never
leave'.

Tony's approach only looks less work if you ignore the hidden cost of
making sure none of your back up tapes or hard drives containing keys
are ever compromised.

In the real world of administration we have to deal with mergers,
acquisitions and de-mergers.

I would like to see a model supported where the machine authentication
key is regarded as being a part of the hardware specific
configuration, just like the MAC address on the network card.

---

From: Tony Finch <[email-masked]>
Date: Wed, 8 Sep 2010 15:18:50 +0100

> hardware, not the software.

If you can afford an HSM per host then you are probably also shelling out
for EV certificates :-)

Also if you have HSMs to keep your keys safe that seems to me to make it
less necessary to have a key per host.

Also a key per host breaks leap-of-faith security (though I don't know of
any TLS clients that do this even though it protects against spoofed
certificates issued by tinpot CAs).

I'm just doubtful that anyone uses a key per host rather than a key per
service.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 10:32:14 -0400

Whatever the cost is of doing this today, it will be much smaller in
the future and that is what we should design protocols to support.

We are not compromising the current definition of the protocol in any
way. The potential impact is either a few lines of code in the cert
handling code to extract a prefix from an extension or a few lines of
code in the cert handling path to calculate the digest and some
additional work on the part of the admin to maintain the key prefixes.

Remember that the principle of labeling keys is already established in
the DKIM specs. That is the established practice and a proposal to
deviate from that practice should require an explanation.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 8 Sep 2010 15:40:21 +0100

> additional work on the part of the admin to maintain the key prefixes.

Somewhere earlier in this thread you described this as zero cost, but that's
not really true: a domain name based query can be launched at the same time
as retrieving A records, but a cert based query has to wait until halfway
through the query, which is likely to add latency.

Of course, the domain-based query could return "look up the hash, please",
then people who don't think they should have 10k expensive keys don't have
to pay the latency price.

> deviate from that practice should require an explanation.

I've lost track of what you mean by labelling. If you mean they should say
what protocol(s) they are good for, then I agree.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 11:46:36 -0400

As with any DNS query, the server can always optimize by pushing out
additional answer records.

There are three options here:

1) Just use the domain name

example.com  CERT blaahhhh

2) Default is the domain name as above, but the X.509 cert MAY contain
an extension that specifies a prefix value that can be used in the
same manner as a DKIM key selector

_cert1.example.com CERT blaaahhhh

3) Use the hash of the cert as the selector

_1f82ba65926afbc2a4bb99b2d09ca90cc2f78645.example.com CERT blaaahhhh

Consequences of the choices is as follows:

Number of keys supported per service
1) Limited to number that can be packed into a DNS response plus signature
2) Unlimited
3) Unlimited

Earliest time key can be fetched
1) Fetching A record for the service
2) Can attempt to fetch with the A record but may need to issue new
query once the prefix is known.
3) After the certificate is presented in the TLS initialization

Administrative Issues
1) Cannot separate management of keys from services
2) Can only use multiple keys per service if the certificate is
generated with the appropriate label.
3) Have to deal with rather large prefixes that have to be typed correctly

Server Administration
1) Allows pre-fetch request
2) Allows pre-fetch request
3) Prevents pre-fetch request (may be considered desirable if you run
a large DNS service)

My original preference was for a label prefix specified in the cert.
Then I was convinced by people here to consider the hash of cert
approach. If this pre-fetch issue is really considered to be a
performance benefit then I will go back to my original label position.

Now in the absence of an ESRV policy record, any crypto is going to be
better than no crypto. The real question therefore is not whether you
turn on SSL, it is whether you ask the user if they should accept the
self-signed cert or not and whether you tell them that the connection
is 'secure' and if so how much certainty you indicate.

The reason I brought up ESRV here now is because without it the whole
key assurance problem could be handled just as well by accepting all
self-signed certs without mentioning the fact.

My preferred approach would be to do the pre-fetch on the ESRV and
A/AAAA record. SRV balancing is potentially a much bigger win than the
single round trip saving we get on prefetching CERT RRs.

Labels also simplify things immensely when we are considering what to
do in the case of SRV and NAPTR records. The question that has to be
considered there is what to do in the case that we have:

_http._tcp.example.com   SRV 1 1 80 host1.beeblebrox.com

OK, now do you want to do the key assurance for example.com or beeblebrox.com?

Depending on the admin setup I can make an argument for both.

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 8 Sep 2010 17:50:36 +0200

> _1f82ba65926afbc2a4bb99b2d09ca90cc2f78645.example.com CERT blaaahhhh

Combining 1 & 3 is possible and do make some sense for performance. You can query for the cert upon connection (in parallel with the TLS connection), and if not found you can re-query once you have the hash.

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 12:12:41 -0400

Agreed.

I still think that you are going to find that a DNS round trip costs
less on average than the key agreement required in the TLS handshake.

If you make the query as soon as you get the cert package, you do not
need the result until after you have generated your secret, encrypted
it, generated the master secret &ct.

Does anyone know what the state of the art is in browser OCSP
handling? How is that managed in the pipeline?

---

From: Adam Langley <[email-masked]>
Date: Wed, 8 Sep 2010 17:45:05 -0400

>From Chrome's point of view:

1) Querying DNS is slow. The median time is about 100ms, with a long
tail (mean is about 350-400ms). Every query is another chance for a
packet loss and a very expensive timeout. Because of this, we very
much wish to minimise the number of different resource record types
needed.

2) OCSP replies are cached in memory and we have the code ready to
cache them on disk also. OCSP replies are typically valid for 7 days.

3) We send the application data as soon as we have validated the
certificate. Thus any lookups which only start after we have the
certificate (i.e. OCSP, CRLs) are on the critical path.

4) OCSP lookups take a median of 400ms (mean: 650ms). That's why
www.google.com is rolling out OCSP stapling.

AGL

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Sep 2010 00:06:58 +0100

Just one question below.

> much wish to minimise the number of different resource record types

The above says you want to reduce the number of different RRs
queried, I don't understand the effect that "different resource
record types" might have?

Ta,
S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 19:10:24 -0400

Thanks,

That is really helpful and I think it pretty much answers the last
point on the other 'revocation thread'. DNS administration processes
have a time period of approximately 1 day to 7 days. If OCSP responses
are cached for 7 days both systems are running in roughly the same
timeframe.

One thought that comes to mind is that we could maybe address the
efficiency issue with DNS RR stapling. That would obviate the need for
the DNS lookup altogether.

The TLS client would have to specify the domain that it was connecting
to of course.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 8 Sep 2010 19:46:08 -0400

I'm assuming by "RR stapling" you mean including the RR and RRSIG in  
the TLS handshake.

I don't think that would be beneficial over simple caching of RRs/ 
RRSIGs .  The stapled value could only be the RR and RRSIG (not the  
full trust chain), since you would need to go to the DNS to know that  
the signing key is still bound to the domain.  That means that you  
still have to perform a DNS query every time a DNSKEY TTL expires.   
That's at least as many DNS queries than you would get by just caching  
the RRSIG, since RRSIG validity periods can be longer than the  
corresponding DNSKEY TTLs.

--Richard

On Sep 8, 2010, at 7:10 PM, Phillip Hallam-Baker wrote:

>> On Wed, Sep 8, 2010 at 12:12 PM, Phillip Hallam-Baker <[email-masked] 
>> > wrote:

---

From: Tony Finch <[email-masked]>
Date: Thu, 9 Sep 2010 02:05:42 +0100

> much wish to minimise the number of different resource record types

It's worth noting that subsequent queries in the same zone will be quicker
than the first query in that zone since the cache already has the
necessary metadata (NS records and DNSKEY + DS trust chain). That's
probably still not fast enough for the Chrome developers :-) but looking
up A, AAAA, and CERT concurrently should help.

Tony.

---

From: Adam Langley <[email-masked]>
Date: Wed, 8 Sep 2010 22:03:20 -0400

> record types" might have?

Each different RR needs a different DNS request (since multiple
queries in a single request doesn't actually work.)

If we assume that the probability of a given DNS request completing
without any packet loss is 99% then the probability of all of a number
of requests going smoothly drops off exponentially.

Now, I don't actually have any data behind that yet, although the
model is a compelling reason to minimise the number of requests in a
latency sensitive situation. I want to get some timings for looking up
TLS related information in DNS for HTTPS requests in the coming weeks.

AGL

---

From: Adam Langley <[email-masked]>
Date: Wed, 8 Sep 2010 22:13:07 -0400

On Wed, Sep 8, 2010 at 7:46 PM, Richard L. Barnes <[email-masked]> wrote:
> I don't think that would be beneficial over simple caching of RRs/RRSIGs .
>  The stapled value could only be the RR and RRSIG (not the full trust
> chain), since you would need to go to the DNS to know that the signing key
> is still bound to the domain.  That means that you still have to perform a
> DNS query every time a DNSKEY TTL expires.  That's at least as many DNS
> queries than you would get by just caching the RRSIG, since RRSIG validity
> periods can be longer than the corresponding DNSKEY TTLs.

Chrome already supports 'RR stapling', although we call it 'chain
embedding'. It's possible to embed a DNSSEC chain in an X.509
certificate and authenticate an HTTPS connection from it.

We only pay attention to the signature expiry in the embedded chain.
Since the TTL of the record isn't signed (only the max TTL), it's
already possible for a network attacker to substitute stale data up to
the limit of the first RRSIG expiry in the chain.

Chain embedding is really design for self-signed certs. It allows them
to be valid without requiring DNSSEC resolution ability on the client.
If one already has a CA signed cert then chain embedding isn't an
option (because the CA won't sign it). In this case, one could imagine
putting the chain in a TLS extension (akin to OCSP stapling). However,
the advantage for a CA signed cert isn't that great. The browser
cannot really avoid the DNS lookup because it would already have
started it before getting the stapled data. It *could* authenticate
the certificate based on the stapled data, saving OCSP lookups(*) and
it could avoid having to wait for the DNS lookup to complete. But a
TLS extension is quite a lot of work just to achieve that.

(*) One might argue that it would be easier for the server to
implement OCSP stapling in order to avoid the OCSP lookup. However,
OCSP stapling has largely been crippled as most CAs now involve an
intermediate certificate, which also needs an OCSP lookup, and OCSP
stapling can only include a single OCSP response. If one were to do
the work of writing a new TLS extension, OCSP multi-stapling might
have more impact.

AGL

---

From: Steve Schultze <[email-masked]>
Date: Wed, 8 Sep 2010 22:47:06 -0400

Adam, I thought I understood how Chrome cert embedding works but to be honest I didn't understand this part of the explanation.  Can you expound?

On Sep 8, 2010, at 10:13 PM, Adam Langley wrote:
> option (because the CA won't sign it).

Won't sign what?

> In this case, one could imagine
> putting the chain in a TLS extension (akin to OCSP stapling).

The cert chain or the DNSSEC chain?

> However,
> started it before getting the stapled data.

Because the DNSSEC chain cannot be embedded simultaneously with the cert chain?

> It *could* authenticate

Why does it require a TLS extension?  You can't do a DNSSEC chain embed and an X.509 embed together?  (yes, I think I understand why this is the case, but it would be helpful for you to explain.)

---

From: Adam Langley <[email-masked]>
Date: Thu, 9 Sep 2010 08:45:27 -0400

> Won't sign what?

The DNSSEC chain is just an X509 extension.
https://www.dnssec-exp.org) is running one now if you want an example.
No CA should sign a certificate with a random extension that they
don't understand.

Embedding DNSSEC chains in X509 extensions is easy on the server side:
no change to the server is needed, you just install a different PEM
file. The disadvantage is that extensions are in the part of the
certificate which is signed. That's fine for self-signed certificates
but precludes using them in CA signed certificates. Even if you could
find a CA that is happy to sign the DNSSEC chain, you would need to
have the CA sign a new certificate each time the chain expired (which
is likely to be once a week.)

> The cert chain or the DNSSEC chain?

The DNSSEC chain.

> Because the DNSSEC chain cannot be embedded simultaneously with the cert chain?

No, the browser would have started the DNS lookup when the HTTPS
connection was started. (It wants to overlap as much as possible for
latency reasons.) By the time that the certificate has been received
the DNS lookup would hopefully have completed.

> Why does it require a TLS extension?  You can't do a DNSSEC chain embed and an X.509 embed together?  (yes, I think I understand why this is the case, but it would be helpful for you to explain.)

In order to put the DNSSEC chain somewhere where the CA doesn't have
to sign it we would need to move it out of the certificate. That means
putting it in another handshake message and that means a TLS extension
to negotiate the inclusion of that handshake message.

AGL

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 9 Sep 2010 08:50:05 -0400

Doesn't this seem kind of dangerous?  How does the browser know that  
the keys presented in the chain are actually keys for the zones in  
question?  Couldn't the trust anchor just make up a set of keys and  
construct a chain?  I realize that in principle, the TA could do this  
already, by faking NS records as well as key/sig records, but this  
barrier seems much lower.

--Richard

On Sep 9, 2010, at 8:45 AM, Adam Langley wrote:

>> Why does it require a TLS extension?  You can't do a DNSSEC chain  
>> embed and an X.509 embed together?  (yes, I think I understand why  
>> this is the case, but it would be helpful for you to explain.)
>

---

From: Adam Langley <[email-masked]>
Date: Thu, 9 Sep 2010 08:57:40 -0400

On Thu, Sep 9, 2010 at 8:50 AM, Richard L. Barnes <[email-masked]> wrote:
> Doesn't this seem kind of dangerous?  How does the browser know that the
> keys presented in the chain are actually keys for the zones in question?
>  Couldn't the trust anchor just make up a set of keys and construct a chain?
>  I realize that in principle, the TA could do this already, by faking NS
> records as well as key/sig records, but this barrier seems much lower.

Yes. Any zone in the path can fake all subsequent elements in the path.

Of course, anyone who controls your DNS can easily get a CA
certificate for your domain as well.

In terms of risk, it's like adding another CA to the 1500-odd root CA
certificates already out there. In terms of benefit, if, as a site
operator, you don't trust some TLD, then you don't have to be in that
TLD. Where as you don't get any say in the CA system.

AGL

---

From: Tony Finch <[email-masked]>
Date: Thu, 9 Sep 2010 14:06:48 +0100

On 9 Sep 2010, at 13:50, "Richard L. Barnes" <[email-masked]> wrote:

> Doesn't this seem kind of dangerous?  How does the browser know that the keys presented in the chain are actually keys for the zones in question?

The first link in the chain has to be signed by the root trust anchor, and the only way to do that is to put it in the root zone. By induction this is true for each child zone in the chain.

DNSSEC can authenticate DNS data regardless of where you get it from.

Tony.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 9 Sep 2010 15:15:06 +0100

> performance benefit then I will go back to my original label position.

Why? My proposal seems less complex (I don't have to change existing
certs): namely, indicate in the pre-fetch response that actually I
need a lookup by certificate hash.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Sep 2010 10:38:18 -0400

> TLD. Where as you don't get any say in the CA system.

I don't want to get into a detailed discussion of trust models here.
But one of the reasons for wanting to use DNSSEC is that it allows the
zone owner to establish full control over their entire trust model on
an enterprise-wide basis over time.

I developed this as a theoretical model for a customer in the SCADA
space last year. There the issue was to have a 5 year and a 10 year
plan for establishing full control of their equipment independent of
any party that they did not have a direct contractual relationship
with (an anticipated regulatory/audit requirement).

The first step is to generate a long term root for the zone. So for
defaultdenysecurity.com I would use trustworthy hardware &ct to
generate a self-signed root with n-of-m keysplitting.

The root is established as a long term (10-20 year) self signed
certificate. This is published in the domain as a trust root,
modifying the original concept to fit in with subsequent discussions
this would be:

defaultdenysecurity.com CERT 0 0 X509ROOT bllaaaaaaaaaah

Depending on your taste you can either use the root key as the KSK for
the zone or use it to sign the KSK for the zone in which case you
would have an ordinary CERT record:

defaultdenysecurity.com CERT 23 33 X509 blleeeegghhhhhhhhh

Here the TAG values MUST match the DNSSEC DS values since that is what
they were for.

The domain defaultdenysecurity.com represents a logical network that
is independent of any physical network it might get service from. At
all times a device that is in the defaultdenysecurity.com logical
network will use the root of trust for defaultdenysecurity.com (i.e.
bllaaaaaaaaah) as its exclusive root of trust.

When a device or application is initialized into the
defaultdenysecurity.com logical network it will (if possible according
to the device constraints) present the fingerprint of the root of
trust it has obtained from the network to the user. It also engages in
a key establishment protocol which ensures that it is granted
authentication credentials for the logical network if and only if it
has successfully acquired the correct root of trust.

Once you have these conditions in place you can then use existing
protocols or new protocols to perform trust root management. For
example the device is not going accept just any DNS resolution service
it is going to exclusively use the DNS resolution service advertised
in the defaultdenysecurity.com DNS zone by means of an ESRV record and
do so by means of a security layer that provides authentication as a
minimum.

Rather than accept every CA root that has a Web Trust audit,
devices/applications can either delegate trust root verification via
SCVP or XKMS or they can employ some trust root management service to
be defined. In either case the service is ultimately authenticated by
the domain root of trust.

If someone does not like the trust criteria defined in a logical
network then they get their own DNS domain name. This infrastructure
is designed to allow control freaks to have full control within the
logical network they define.

Curating the roots of trust makes only limited sense in the context of
Web site security. It makes a lot more sense in the case of code
signing.

So for example, a CA is found to have been co-erced by their
government into signing code with a back door, so the cross
certificate to the domain root of trust is revoked.

In summary, what we are talking about is not necessarily *adding* one
more CA to the roots of trust. It is *replacing* the 1500 roots of
trust with a single root that is under direct control.

In practice of course this would be a rather expensive infrastructure
to maintain on a single site basis so most enterprises would outsource
some or all of the management processes to parties that they have a
direct contractual relationship with. The important thing is the
ability to control that choice and select a different provider if one
defaults.

---

From: [email-masked]
Date: Sat, 11 Sep 2010 01:45:01 +0000

> As presenting a self-signed cert will, for >99% of the clients, trigger a security warning - I'm not sure that's a good transition mechanism. Telling the client that if you do DNSSEC (and we suspec…

	er... plz explain how finding a CERT RR inplies DNSSEC?

--bill

---

From: [email-masked]
Date: Sat, 11 Sep 2010 01:47:37 +0000

when you/we mention domain name owner, aren't we really refering to 
the domain zone administrator?

I've been told that these days conflating the two roles is generally 
in error, since most domain name owners rarely operate the domain zone.

--bill

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 10 Sep 2010 23:26:46 -0400

That is definitely a complication in the model and it keeps cropping up.

In the general case the Web host, the DNS registrar and the DNS admin are
all separate from the domain name owner.

It is actually possible to be in the Web Hosting services business and not
do any of the above or even have a data center.

On Fri, Sep 10, 2010 at 9:47 PM, <[email-masked]> wrote:

> specifying, since it's up to the relying party to decide what validation he
> does.
> > >
> > > The domain owner can state a preference and it is up to the relying
> party to decide, that's why we state that this preference is advisory.
> > >
> > >>  If the domain owner doesn't want the RP to perform any X.509 path
> validation, then shouldn't he just present a self-signed cert?
> > >
> > > As presenting a self-signed cert will, for >99% of the clients, trigger
> a security warning - I'm not sure that's a good transition mechanism.
> Telling the client that if you do DNSSEC (and we suspect you do, as you
> found this CERT in DNS) that's good enough is nicer and will make early
> adopters happier.
> > >
> > >        jakob
> > >
> > >
> >
> >
> >
> > --

---

From: [email-masked]
Date: Sat, 11 Sep 2010 04:10:25 +0000

ok - so lets trim out some of the confusion.

 posit an IP address (routed).

 attached to that IP address are zero or more domain names.

 each domain name may have zero or more httpd processes running.
 and
 each domain name may have zero or more sshd processes running.

 and for the purpose of discussion, the following DNS entries
 are created:

example.org.  IN SOA {PHB@  };
	in ns  foo
	in ns  bar
	in cert { ...Ev0 }
;
`
AS	in a 192.168.18.53
	in cert { ...Ev1 }
;
BM	in ns warble.bm
	in ns screech.bm
	in cert { ...iEv2 }
;

so... 

	who owns  example.org?  == PHB
	who owns  AS.example.org?  (I'd say PHB controls it and the entries, regardless
		of the legal ownership of the string.)
	who owns  BM.example.org?  (a bit more nebulous, but prolly BM)

the nut to crack here is, who caused the certs Ev1 & Ev2 to be created and _installed_ there?

I'd sort of like to leave the webhosting cruft for another thread.

--bill

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 11 Sep 2010 07:36:11 -0700

>the nut to crack here is, who caused the certs Ev1 & Ev2 to be created and _installed_ there?

Note that the certificates in question have to be used somewhere, such as in the HTTPS servers on AS and BM. Thus, it isn't really that important who caused the certs to be created, just who is using them. That is, these certs don't exist in a vacuum: they are being used with servers of some sort.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 11 Sep 2010 11:01:33 -0400

It really depends on how they are being used.

The problem is that turning on use of crypto is a really low bar. The real
question is what you tell the user.

If the user is being told either nothing or given one of those idiot
warnings 'do you want to do this securely' then there is no problem at all.

If on the other hand the user either expected security (they typed in HTTPS)
or they are being told they are 'safe' then it matters quite a bit.

In addition there are several protocols like OpenID where there are
statements of the form 'use SSL to secure this transaction'. A man in the
middle issue there could break the security assumptions.

On Sat, Sep 11, 2010 at 10:36 AM, Paul Hoffman <[email-masked]>wrote:

> Note that the certificates in question have to be used somewhere, such as
> in the HTTPS servers on AS and BM. Thus, it isn't really that important who
> caused the certs to be created, just who is using them. That is, these certs
> don't exist in a vacuum: they are being used with servers of some sort.
>
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 11 Sep 2010 08:39:58 -0700

At 11:01 AM -0400 9/11/10, Phillip Hallam-Baker wrote:

It really depends on how they are being
used.

What does that mean?

The problem is that turning on use of
crypto is a really low bar. The real question is what you tell the
user.

If the user is being told either nothing
or given one of those idiot warnings 'do you want to do this securely'
then there is no problem at all.

If on the other hand the user either
expected security (they typed in HTTPS) or they are being told they
are 'safe' then it matters quite a bit.

Can you be maybe a tad more specific? If a CERT record is
cryptographically tied to a certificate from the TLS server, why does
who created the certificate matter at all?

In addition there are several protocols
like OpenID where there are statements of the form 'use SSL to secure
this transaction'. A man in the middle issue there could break the
security assumptions.

Again, a specific example like Bill gave would be helpful when
you make statements like that.

On Sat, Sep 11, 2010 at 10:36 AM, Paul
Hoffman <[email-masked]>
wrote:

>the nut to crack here is, who caused the certs Ev1 & Ev2 to be
created and _installed_ there?

Note that the certificates in question have to be used
somewhere, such as in the HTTPS servers on AS and BM. Thus, it isn't
really that important who caused the certs to be created, just who is
using them. That is, these certs don't exist in a vacuum: they are
being used with servers of some sort.

---

From: [email-masked]
Date: Sat, 11 Sep 2010 15:42:22 +0000

> Note that the certificates in question have to be used somewhere, such as in the HTTPS servers on AS and BM. Thus, it isn't really that important who caused the certs to be created, just who is usi…

	so let me punt a couple of operationally driven questions.

in the case of BM, this looks like what folks call "delegation" - so there should be
another zone stanza like so:

bm.example.org.  IN SOA  {BM@ };
	in warble
	in screech
	in cert { ... Ev6 }
;
www	in a 10.10.10.22
;

	so there now seem to be -TWO- cert records for bm.example.org, one in the parent (Ev2)
	and one in the child, (Ev6).  Did BM create/install both of them and forgot to update
	one?  Would PHB -allow- BM to update the parent zone?  Is PHB injecting Ev2 as a DoS 
	against a (former) client?

	as to your assertion that certs don't exist in a vacuum, you might be correct. Most certs
	are used by applications.  You clearly have marked your bias toward the PoV that this ML
	should focus specifically on TLS or other application key distribution. I still feel
	that there is value in the identification of the target node, where applications run.
	Your "vacuum", My node-Identity.

--bill

---

From: [email-masked]
Date: Sat, 11 Sep 2010 15:48:57 +0000

On Sat, Sep 11, 2010 at 08:39:58AM -0700, Paul Hoffman wrote:

<div>Can you be maybe a tad more specific? If a CERT record is
cryptographically tied to a certificate from the TLS server, why does
who created the certificate matter at all?</div>
<div><br></div>

	adn what happens when it isn't because:

	a) your parent is trying to tell you something.. like pay your bills?

	or 

	b) because the application support staff isn't communicating with the
	   DNS admin and didn't get the "correct" cert into the zone.

	just some operationally oriented questions...

--bill

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 11 Sep 2010 09:55:15 -0700

You are correct about the operational issues. All the proposals here say, in essence, "Dear DNS admin: add this data whose type you are probably unfamiliar to the DNS for my zone, and also I will give you periodic updates that could come faster than the A record updates I give you". There is an operational cost on someone else (the DNS admin) that hopefully outweighed by the security benefit (to the host admin).

This is not a problem. The proposals are pretty clear what is expected from the DNS admin; there is nothing here that would cause a particular domain name to have to be maintained past the operational end of the A record's life; the host admin, not the DNS admin, generates the material to be put in the DNS; nothing proposed yet would require rapid (<5 minute) changes under normal security circumstances.

If some of those assumptions are violated, we probably need to look more carefully at the DNS operational issues for that proposal.

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked]
Date: Sat, 11 Sep 2010 17:01:59 +0000

> If some of those assumptions are violated, we probably need to look more carefully at the DNS operational issues for that proposal.

	thanks.  just saying that we have been down this path before (the first iteration
	of DNSSEC) when the securoty folks were in charge of the design.  when it came to
	actual operations, the operational costs were so high that it was undepolyable ..
	due to too high a frequency of communications between child and parent. 

	lets not repeat tht mistake.

--bill

---

From: Tony Finch <[email-masked]>
Date: Sun, 12 Sep 2010 18:36:35 +0100

On 11 Sep 2010, at 16:42, [email-masked] wrote:
> 
> in the case of BM, this looks like what folks call "delegation" - so there should be another zone stanza like so:
> 
>    so there now seem to be -TWO- cert records for bm.example.org, one in the parent (Ev2) and one in the child, (Ev6).

You can't have records in the parent at a delegation other than NS, DS, RRSIG, and NSEC or NSEC3 (plus perhaps glue address records, but that would be weird). Ev2 is definitely forbidden.

Tony.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 14 Sep 2010 21:52:20 -0400

> 	lets not repeat tht mistake.

Well when we wrote RFC3008 we were trying to learn from the difficulties 
of deploying dynamic information in DNS, which this is.

Thus the document recommends that implementation allow "fine grain"
write control to DNS data.
"Fine grain" here is to the name level or the RR Type level.
To my most DNS servers that support dynamic update support this
fine grain write access control.

So it is quite easy to give the application operator write access for a 
specific type at a specified name.
The difficulty is going to be if multiple applications want to all add 
CERT records at the same name as the applications might stomp on each 
other by deleting each others CERT record by not specifying
exactly which CERT record to delete.

<insert standard DNS advise: use application specific type OR 
application specific names such as _app-foo._tcp.BM.example.net.?

When using Dynamic Update  the only action for the DNS admin is to
set up the  write access rule and do the key exchange with the 
application operator and then to delete the access when the application 
has gone away. In no case will the DNS operator have to perform time 
critical updates to DNS data.

	Olafur

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Sep 2010 23:32:49 -0400

+1 (for the requirement)

On the implementation side, I think that using prefixes formed from the
certificate hash value is a better approach than attempting separation by
protocol.

* It is more general, any application that uses certs can use the mechanism
regardless of whether they have an SRV prefix.

* It also addresses the case where there are multiple servers servicing the
same protocol that might tread on each other.

Each app can then update their own cert records independently. The only case
in which a collision could occur is if two servers were both using the same
cert and one thought it should be deleted while the other did not.

On Tue, Sep 14, 2010 at 9:52 PM, Olafur Gudmundsson <[email-masked]> wrote:

>>> You are correct about the operational issues. All the proposals here say,
>>> in essence, "Dear DNS admin: add this data whose type you are probably
>>> unfamiliar to the DNS for my zone, and also I will give you periodic updates
>>> that could come faster than the A record updates I give you". There is an
>>> operational cost on someone else (the DNS admin) that hopefully outweighed
>>> by the security benefit (to the host admin).
>>>
>>> This is not a problem. The proposals are pretty clear what is expected
>>> from the DNS admin; there is nothing here that would cause a particular
>>> domain name to have to be maintained past the operational end of the A
>>> record's life; the host admin, not the DNS admin, generates the material to
>>> be put in the DNS; nothing proposed yet would require rapid (<5 minute)
>>> changes under normal security circumstances.
>>>
>>> If some of those assumptions are violated, we probably need to look more
>>> carefully at the DNS operational issues for that proposal.
>>>
>>> --Paul Hoffman, Director
>>> --VPN Consortium
>>>
>>
>>
> Well when we wrote RFC3008 we were trying to learn from the difficulties of
> deploying dynamic information in DNS, which this is.
>
> The difficulty is going to be if multiple applications want to all add CERT
> records at the same name as the applications might stomp on each other by
> deleting each others CERT record by not specifying
> <insert standard DNS advise: use application specific type OR application
> specific names such as _app-foo._tcp.BM.example.net.?
>
> set up the  write access rule and do the key exchange with the application
> operator and then to delete the access when the application has gone away.
> In no case will the DNS operator have to perform time critical updates to
> DNS data.
>
>        Olafur
>

---

From: Steve Schultze <[email-masked]>
Date: Tue, 14 Sep 2010 23:41:38 -0400

On Sep 14, 2010, at 11:32 PM, Phillip Hallam-Baker wrote:
> On the implementation side, I think that using prefixes formed from the certificate hash value is a better approach than attempting separation by protocol.
> 
> * It is more general, any application that uses certs can use the mechanism regardless of whether they have an SRV prefix.
> 
> * It also addresses the case where there are multiple servers servicing the same protocol that might tread on each other.

With the downside being that you can't start your lookup until you have received and hashed the cert... or if we go with keys, received and parsed the cert, then hashed the key.  Right?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Sep 2010 00:44:29 -0400

Using the suggestions from the Google camp it is possible to finesse this so
that pre-fetching is still possible in the simplest cases and the hash value
approach is only used in cases where it is required.

This is all explained in my draft:

https://tools.ietf.org/html/draft-hallambaker-certhash-00

The simple case would be

   example.com     CERT DPKIX 1 SHA256
                   KR1L0GbocaIOOim1+qdHtOSrDcOsGiI2NCcxuX2/Tqc

If we need to use prefixing for whatever reason the same example might be
given as:

example.com     CERT DPTR 1 SHA256 "cert.example.com"

_KR1L0GbocaIOOim1+qdHtOSrDcOsGiI2NCcxuX2/Tqc.cert.example.com DPKIX
                  1 SHA256 KR1L0GbocaIOOim1+qdHtOSrDcOsGiI2NCcxuX2/Tqc

[I am not sure that the DNS server will take a string argument in this
particular case, I have represented it as a string for clarity]

In practice, an intelligent DNS server might well be able to push out all
the necessary records as additional answers to the original query.

On Tue, Sep 14, 2010 at 11:41 PM, Steve Schultze <[email-masked]> wrote:

> > * It is more general, any application that uses certs can use the
> mechanism regardless of whether they have an SRV prefix.
> >
> > * It also addresses the case where there are multiple servers servicing
> the same protocol that might tread on each other.
>
> With the downside being that you can't start your lookup until you have
> received and hashed the cert... or if we go with keys, received and parsed
> the cert, then hashed the key.  Right?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Sep 2010 00:44:29 -0400

The simple case would be

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Sep 2010 00:44:29 -0400

The simple case would be

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Sep 2010 00:44:29 -0400

The simple case would be

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 15 Sep 2010 08:51:34 +0200

On 15 sep 2010, at 06.44, Phillip Hallam-Baker wrote:

> In practice, an intelligent DNS server might well be able to push out all the necessary records as additional answers to the original query.

IIRC, the reason for storing the certs/fingerprins using a hashed prefix would be limit the packet size. Pushing out prefixed RRs together with the referral would be kind of counterproductive, don't you think?

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Sep 2010 07:46:00 -0400

Agreed that it is difficult to optimize the CERT chain in isolation.

It is much easier to optimize the lookup if the DNS server is doing a
service lookup and knows the purpose with greater clarity.

On Wed, Sep 15, 2010 at 2:51 AM, Jakob Schlyter <[email-masked]> wrote:

> IIRC, the reason for storing the certs/fingerprins using a hashed prefix
> would be limit the packet size. Pushing out prefixed RRs together with the
> referral would be kind of counterproductive, don't you think?
>
>        jakob
>
>