Subject: Re: [keyassure] Thousands of servers on one domain name

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 8 Sep 2010 15:10:09 -0500 (GMT-05:00)

Ben and all,

-----Original Message-----
From: Ben Laurie
Sent: Sep 8, 2010 9:40 AM
To: Phillip Hallam-Baker
Cc: Tony Finch , "[email-masked]"
Subject: Re: [keyassure] Thousands of servers on one domain name

On 8 September 2010 15:32, Phillip Hallam-Baker <[email-masked]> wrote:

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.

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.

This is a really good point IMO.

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.

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.

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.

On Wed, Sep 8, 2010 at 10:18 AM, Tony Finch <[email-masked]> wrote:
> On Wed, 8 Sep 2010, Phillip Hallam-Baker wrote:
>>
>> 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.
>
> 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.
>

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

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

Regards,
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827