Re: [DNSOP] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC

Stephen Farrell wrote: > > On 04/10/10 15:37, Martin Rex wrote: > > One thing that needs to be addressed/solved is the key/cert rollover > > for any TLS-Server, so that it is possible to list more than one > > server cert as "valid" for a Server through DNS, at least for the > > time of the transi

Re: [DNSOP] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

For the past five years, CA certificates have been divided into Domain Validated and Extended Validated. As some of you know, I instigated the process that led to the creation of EV certs because I was very worried about the low quality of many DV certificates. Some DV certificates are of very

Re: [DNSOP] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

On Sun, Oct 03, 2010 at 11:14:23AM -0400, Phillip Hallam-Baker wrote: > What is actually being proposed is to replace the fifteen year established > system of CAs with a new scheme starting in November. [. . .] > I really don't think that we want to replace the existing infrastructure a > new PKI

Re: [DNSOP] Cert Enumeration and Key Assurance With DNSSEC

The reason I did so was that I did not believe that the initial presentation of KEYASSURE to the wider Internet community gave an accurate or full description of what the intended proposal was. Since neither of the proposers took any notice of my repeated requests to correct this situation, I deci

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On 2010-10-04, at 14:13, Tony Finch wrote: > One thing that is missing is any description of the kind of load you > expect the service to bear. Would it be OK if a vendor sold millions of > DSL modems that hit data.iana.org every time they recovered from a power > loss? This, to me, is an operat

Re: [DNSOP] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC

Hi - DNSSEC seems to be picking on PKIX and vice versa - maybe the right answer is both? DNSSEC provides a "secure" association FROM the name TO the IP address. But the DNS domain owner tends not to be the host owner so this asserted association may not reflect the intent of the host owner.

Re: [DNSOP] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC

Hi - DNSSEC seems to be picking on PKIX and vice versa - maybe the right answer is both? DNSSEC provides a "secure" association FROM the name TO the IP address. But the DNS domain owner tends not to be the host owner so this asserted association may not reflect the intent of the host owner.

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On Mon, 4 Oct 2010, Joe Abley wrote: > > I think some of your observations (those that relate to root KSK > management in general, as described in the DPS) would have been good to > hear before July, during the design process. Yes :-/ I was still only starting to get to grips with key management b

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On Mon, 4 Oct 2010, Joe Abley wrote: > On 2010-10-04, at 13:41, Tony Finch wrote: > > On Mon, 4 Oct 2010, Jakob Schlyter wrote: > >> > >> RFC 5011 is not very useful if the active KSK is rendered in-operational > >> ("lost") > > > > Er, yes it is. You have a pre-published standby SEP key > > No. We

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On 2010-10-04, at 13:41, Tony Finch wrote: > On Mon, 4 Oct 2010, Jakob Schlyter wrote: >> >> RFC 5011 is not very useful if the active KSK is rendered in-operational >> ("lost") > > Er, yes it is. You have a pre-published standby SEP key No. We don't. Joe ___

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On 2010-10-04, at 12:53, Tony Finch wrote: > On Mon, 4 Oct 2010, Joe Abley wrote: >> On 2010-10-04, at 11:33, Tony Finch wrote: >>> On Mon, 4 Oct 2010, Joe Abley wrote: I have not heard a clear description of a problem yet >>> >>> How can a system that missed a TA rollover bootstrap i

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On Mon, 4 Oct 2010, Jakob Schlyter wrote: > > RFC 5011 is not very useful if the active KSK is rendered in-operational > ("lost") Er, yes it is. You have a pre-published standby SEP key which validators are ready to use as a trust anchor, so you can immediately promote it to being the operational

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On 2010-10-04, at 12:56, Tony Finch wrote: > On Mon, 4 Oct 2010, Jakob Schlyter wrote: >> >> Depending on the type of compromise, a RFC 5011 may not be appropriate. > > RFC 5011 allows for smooth operation across compromise or loss of the > active KSK, or compromise or loss of the backup KSK. O

Re: [DNSOP] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

On 4 okt 2010, at 17.12, Marsh Ray wrote: > Say, what's the link to the Internet Draft proposal we're discussing anyway? https://datatracker.ietf.org/doc/draft-hoffman-keys-linkage-from-dns/, among others. j ___ DNSOP mailing list DNSOP@ietf.

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On 4 okt 2010, at 18.56, Tony Finch wrote: > On Mon, 4 Oct 2010, Jakob Schlyter wrote: >> >> Depending on the type of compromise, a RFC 5011 may not be appropriate. > > RFC 5011 allows for smooth operation across compromise or loss of the > active KSK, or compromise or loss of the backup KSK. On

Re: [DNSOP] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

Marsh Ray wrote: > > On 10/04/2010 09:37 AM, Martin Rex wrote: > > > > It seems that you do not realize that the entire TLS PKI security model, > > as far as the automatic / no-prompt "server endpoint identification" is > > concerned, has always been relying completely on that DNS data being > > a

Re: [DNSOP] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC

On 04/10/10 15:37, Martin Rex wrote: > One thing that needs to be addressed/solved is the key/cert rollover > for any TLS-Server, so that it is possible to list more than one > server cert as "valid" for a Server through DNS, at least for the > time of the transition/rollover. Maybe a side-issue

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On Mon, 4 Oct 2010, Jakob Schlyter wrote: > > Depending on the type of compromise, a RFC 5011 may not be appropriate. RFC 5011 allows for smooth operation across compromise or loss of the active KSK, or compromise or loss of the backup KSK. Only if both of them are simultaneously lost or compromis

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On Mon, 4 Oct 2010, Joe Abley wrote: > On 2010-10-04, at 11:33, Tony Finch wrote: > > On Mon, 4 Oct 2010, Joe Abley wrote: > >> > >> I have not heard a clear description of a problem yet > > > > How can a system that missed a TA rollover bootstrap its DNSSEC validator? > > The same way that it boot

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On 4 Oct 2010, at 16:34, Joe Abley wrote: > On 2010-10-04, at 11:18, Tony Finch wrote: > >> It isn't immediately clear to me from the root KSK DPS whether you expect >> RFC 5011 to work in the event of a compromise. >> > > We seem once again to be moving from the subject at hand to a review and

Re: [DNSOP] Cert Enumeration and Key Assurance With DNSSEC

Phillip, you present your views by cross-posting several other IETF mailing list without posting this to keyass...@ietf.org. This doesn't give potential readers full picture about what's happening in the keyassure and what is the general consensus in the list. So please all - if you want to

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On Sun, Oct 03, 2010 at 01:18:01PM -0400, Joe Abley wrote: > > I'm not entirely sure the answer shouldn't be "because we manage the > keys, and we say so" actually. I think I've made this argument before, but the above seems to me to be one of two possibly relevant perspectives in respect of keys

Re: [DNSOP] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

On 10/04/2010 09:37 AM, Martin Rex wrote: Phillip Hallam-Baker wrote: The problem with the DNSSEC path is that it is vulnerable to attacks against the information input to the DNS system. The weakest link there is the safeguards on registration of the DNS names. It seems that you do not reali

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On 4 okt 2010, at 17.18, Tony Finch wrote: > This argument also implies that RFC 5011 cannot be used to roll over root > trust anchors in the event of a compromise. Depending on the type of compromise, a RFC 5011 may not be appropriate. > It isn't immediately clear to me from the root KSK DPS wh

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On 2010-10-04, at 11:33, Tony Finch wrote: > On Mon, 4 Oct 2010, Joe Abley wrote: >> >> I have not heard a clear description of a problem yet > > How can a system that missed a TA rollover bootstrap its DNSSEC validator? The same way that it bootstraps itself at day zero. Joe __

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On 2010-10-04, at 11:18, Tony Finch wrote: > It isn't immediately clear to me from the root KSK DPS whether you expect > RFC 5011 to work in the event of a compromise. > > [...] We seem once again to be moving from the subject at hand to a review and discussion of the KSK DPS. I would prefer t

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On Mon, 4 Oct 2010, Joe Abley wrote: > > I have not heard a clear description of a problem yet How can a system that missed a TA rollover bootstrap its DNSSEC validator? It might have missed a rollover because: * It is an old software distribution that has just been installed; * It is some old ha

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On 2010-10-04, at 11:24, bmann...@vacation.karoshi.com wrote: >>> So, rather than designing a bunch of kludgy workarounds, it would be better >>> to ask >>> what the right thing to do is, even if that requires changing some >>> preexisting >>> document. >> >> Workarounds to what? >> >> I have

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On Mon, Oct 04, 2010 at 11:14:20AM -0400, Joe Abley wrote: > > On 2010-10-04, at 11:11, Eric Rescorla wrote: > > > Carefully specified, perhaps, but what you're saying here also makes me > > think it was > > also incorrectly specified, since, as I said, the technique I described is > > well-kn

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On Sun, 3 Oct 2010, Joe Abley wrote: > > At least some of the cases we're talking about involve signatures > necessarily made by keys after an emergency key roll which has taken > place because the old key has been compromised. Such signatures are > worthless. This argument also implies that RFC 5

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On 2010-10-04, at 11:11, Eric Rescorla wrote: > Carefully specified, perhaps, but what you're saying here also makes me think > it was > also incorrectly specified, since, as I said, the technique I described is > well-known, > and failing to do so leads to precisely the complications that ar

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On Mon, Oct 4, 2010 at 7:56 AM, Joe Abley wrote: > Hi, > > On 2010-10-04, at 10:31, Eric Rescorla wrote: > > > On Sun, Oct 3, 2010 at 10:54 AM, Joe Abley wrote: > > > >> On 2010-10-03, at 13:31, Eric Rescorla wrote: > >> > >> > I'm asking because I'm pretty familiar with cryptography and I know

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On Mon, Oct 4, 2010 at 7:56 AM, Joe Abley wrote: > Hi, > > On 2010-10-04, at 10:31, Eric Rescorla wrote: > > > On Sun, Oct 3, 2010 at 10:54 AM, Joe Abley wrote: > > > >> On 2010-10-03, at 13:31, Eric Rescorla wrote: > >> > >> > I'm asking because I'm pretty familiar with cryptography and I know

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

I think it would depend on the HSMs. In at least some of them, it's the card keys that are important and you could have a disjoint set of card keys for K_{n+1} -Ekr On Mon, Oct 4, 2010 at 7:52 AM, Paul Hoffman wrote: > At 7:31 AM -0700 10/4/10, Eric Rescorla wrote: > >On Sun, Oct 3, 2010 at 10

Re: [DNSOP] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

Phillip Hallam-Baker wrote: > > The attack surface is the number of paths that are open to an attacker. > > In the current model there is only one trust path, the PKIX path. > > In the new model, the attacker has a choice of trust paths, the PKIX path > and the DNSSEC path and they can attack ei

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

Hi, On 2010-10-04, at 10:31, Eric Rescorla wrote: > On Sun, Oct 3, 2010 at 10:54 AM, Joe Abley wrote: > >> On 2010-10-03, at 13:31, Eric Rescorla wrote: >> >> > I'm asking because I'm pretty familiar with cryptography and I know that >> > keys don't suddenly become >> > worthless just because

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

At 7:31 AM -0700 10/4/10, Eric Rescorla wrote: >On Sun, Oct 3, 2010 at 10:54 AM, Joe Abley ><jab...@hopcount.ca> wrote: > > >On 2010-10-03, at 13:31, Eric Rescorla wrote: > >> I'm asking because I'm pretty familiar with cryptography and I know that >> keys don't suddenl

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On Sun, Oct 3, 2010 at 10:54 AM, Joe Abley wrote: > > On 2010-10-03, at 13:31, Eric Rescorla wrote: > > > I'm asking because I'm pretty familiar with cryptography and I know that > keys don't suddenly become > > worthless just because they get past their intended use lifetime. The > semantics of