Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

["Jeffrey A. Williams" <[e-mail]>]

Ilari and all,


-----Original Message-----
>From: Ilari Liusvaara <[e-mail]>
>Sent: Nov 3, 2010 1:55 PM
>To: Phillip Hallam-Baker <[e-mail]>
>Cc: Tony Finch <[e-mail]>, [e-mail], Paul Hoffman <[e-mail]>
>Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns
>
>On Wed, Nov 03, 2010 at 01:14:11PM -0400, Phillip Hallam-Baker wrote:
>> 
>> There are certainly issues that arise with prefixes as I mentioned in
>> my other post. But they are tractable provided that:
>> 
>> 1) You are prepared to allow an additional DNS round trip.
>> 2) You are prepared to introduce a new DNS RR.
>
>Considering the adoption of CERT RR, CERT RR can almost be treated as
>new RR.
>
>And there's a diffrence between having to serialize the query and
>firing off the query in parallel with some other qurey one would have
>to do anyway.
>
>> We have to keep an eye on efficiency, but anything we do here is going
>> to depend on deployment of new DNS support infrastructure and require
>> transport that supports new RRs.
>
>Well, there's RFC 3597. But of course, new RRs (even if RFC 3597-compliant)
>have issues with adminstration.
>
>> Certificates typically bind to an entire domain.
>
>They may, or they may not. Some services use certificates in bizarre
>manner and can't share them with anything.
>
>> Statements concerning configuration of a security policy naturally
>> bind to a specific service at a domain.
>
>If you think HSTS is good example of security policy, consider that
>HSTS is really a special kind of protcol-level redirect and is only
>well-defined because of interactions between HSTS spec and HTTPS
>spec.
>
>That's why I think that records specifying secure equivalent of service
>must specify where to locate the service and how to connect to it
>(there are essentially two ways).
>
>> When we start to look at the consequences of outsourcing, the fact
>> that I have outsourced my Web site to outsource.net does not
>> necessarily mean I want to trust them with my mail service so maybe
>> the assumption that certificates are global to a domain also starts to
>> break down.
>
>Actually, HTTP is just about the worst in this regard since it does
>not support any kind of protocol-specific redirect from DNS. Yes, it
>supports CNAME, but CNAME isn't prtocol-specific.
>
>SMTP has MX records, many protocols have SRV, but HTTP does not have
>anything like that.
> 
>> So I am thinking that we are going to end up with a requirement for
>> protocol specific key assurance.
>
>Actually, at key assurance level, port numbers/services only matter
>if you can partition port numbers/services (which might not be
>possible) or if you have services with different security levels on
>one name (to prevent attacking higher-security services using stolen
>key from lower-security service).

  My take is that this all gets back to getting the CA's cleaned
up if possible AND eliminating the COI in respect to some few CA's
also being trust anchors.  Becaues if a key is presented from a
lower-security service that is a qualified CA and perhaps a Trust
Anchor as well, you end up with a obvious problem that is difficult
to actually solve.  
>
>-Ilari
>_______________________________________________
>keyassure mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/keyassure
Regards,
Jeffrey A. Williams
"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
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402 
E-Mail [e-mail]
Phone: [phone]