Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt
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 suddenly become
worthless just because they get past their intended use lifetime. The
semantics of signature
security of old keys is a lot more complicated than that.
The context here is the publication of DNSSEC trust anchors for the root
zone.
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.
I don't think this follows.
It's pretty commonly suggested that at the time you roll out key K_n you
also *immediately* generate
key K_{n+1} and produce a certificate signing K_{n+1} with K_n. Since all
that is required for security
is that the signature itself take place prior to the compromise of K_n this
allows for rollover even
if K_n is subsequently compromised, provided that the relying party can
verify that the signature
on K_{n+1} was computed before the compromise date. There are a variety of
techniques for
doing this, e.g., hash commitment, Haber-Stornetta timestamping, etc.
-Ekr
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
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
mailto:jab...@hopcount.cajab...@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 suddenly become
worthless just because they get past their intended use lifetime. The
semantics of signature
security of old keys is a lot more complicated than that.
The context here is the publication of DNSSEC trust anchors for the root zone.
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.
I don't think this follows.
It's pretty commonly suggested that at the time you roll out key K_n you also
*immediately* generate
key K_{n+1} and produce a certificate signing K_{n+1} with K_n. Since all that
is required for security
is that the signature itself take place prior to the compromise of K_n this
allows for rollover even
if K_n is subsequently compromised, provided that the relying party can verify
that the signature
on K_{n+1} was computed before the compromise date. There are a variety of
techniques for
doing this, e.g., hash commitment, Haber-Stornetta timestamping, etc.
Does the create your next key immediately process work with HSMs if you don't
have 2x the number you would normally have in production? I'm no fan of HSMs
for a system like DNSSE that often needs operational agility, but it seems like
I'm in the minority here.
--Paul Hoffman, Director
--VPN Consortium
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
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 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 suddenly become worthless just because they get past their intended use lifetime. The semantics of signature security of old keys is a lot more complicated than that. The context here is the publication of DNSSEC trust anchors for the root zone. 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. I don't think this follows. In the context of our discussion, it does. We are discussing arrangements for publishing a trust anchor for a key whose management has already been carefully specified, and does not include (for example) pre-generation of the next key in the way you suggest. I think it's perfectly valid to discuss the management of the root zone KSK, ideally with careful reference to the DPS that ICANN published. However, that's not what we're talking about here. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 paul.hoff...@vpnc.org wrote:
At 7:31 AM -0700 10/4/10, Eric Rescorla wrote:
On Sun, Oct 3, 2010 at 10:54 AM, Joe Abley mailto:jab...@hopcount.ca
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 suddenly become
worthless just because they get past their intended use lifetime. The
semantics of signature
security of old keys is a lot more complicated than that.
The context here is the publication of DNSSEC trust anchors for the root
zone.
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.
I don't think this follows.
It's pretty commonly suggested that at the time you roll out key K_n you
also *immediately* generate
key K_{n+1} and produce a certificate signing K_{n+1} with K_n. Since all
that is required for security
is that the signature itself take place prior to the compromise of K_n
this allows for rollover even
if K_n is subsequently compromised, provided that the relying party can
verify that the signature
on K_{n+1} was computed before the compromise date. There are a variety of
techniques for
doing this, e.g., hash commitment, Haber-Stornetta timestamping, etc.
Does the create your next key immediately process work with HSMs if you
don't have 2x the number you would normally have in production? I'm no fan
of HSMs for a system like DNSSE that often needs operational agility, but it
seems like I'm in the minority here.
--Paul Hoffman, Director
--VPN Consortium
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt
On Mon, Oct 4, 2010 at 7:56 AM, Joe Abley jab...@hopcount.ca wrote: Hi, On 2010-10-04, at 10:31, 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 suddenly become worthless just because they get past their intended use lifetime. The semantics of signature security of old keys is a lot more complicated than that. The context here is the publication of DNSSEC trust anchors for the root zone. 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. I don't think this follows. In the context of our discussion, it does. We are discussing arrangements for publishing a trust anchor for a key whose management has already been carefully specified, and does not include (for example) pre-generation of the next key in the way you suggest. 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 are at issue here. 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. -Ekr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt
On Mon, Oct 4, 2010 at 7:56 AM, Joe Abley jab...@hopcount.ca wrote: Hi, On 2010-10-04, at 10:31, 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 suddenly become worthless just because they get past their intended use lifetime. The semantics of signature security of old keys is a lot more complicated than that. The context here is the publication of DNSSEC trust anchors for the root zone. 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. I don't think this follows. In the context of our discussion, it does. We are discussing arrangements for publishing a trust anchor for a key whose management has already been carefully specified, and does not include (for example) pre-generation of the next key in the way you suggest. 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 are at issue here. 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. -Ekr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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-known, and failing to do so leads to precisely the complications that are at issue here. Regardless of what you think of it, what we have is what we have. Specifying a trust anchor publication strategy that works with something different seems a little pointless. i think the correct point is, this work documents what _was_ done, eg. a historical fact. It also lays out what the authors think is best practice, given the current constraints. Its kind of tough to argue w/ someones beliefs. Facts - yes, beliefs - not so much. If there are factual errors in what occured, those can and should be corrected. 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 not heard a clear description of a problem yet, just a lot of possible solutions. And yet, you were part of a team that spent hundreds of thousands of dollars and several man-years working on a solution to a, as you state above, to a problem without a clear statement? I'd susggest that there might be better ways to do key management and that EKR might have some good ideas on the subject. But thats _future_ work. --bill Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 not heard a clear description of a problem yet, just a lot of possible solutions. And yet, you were part of a team that spent hundreds of thousands of dollars and several man-years working on a solution to a, as you state above, to a problem without a clear statement? The solutions I'm talking about are those recently described involving the chain of trust from old keys through successive keys. The problems that those specific solutions are intended to solve have not been described. As you know. I'd susggest that there might be better ways to do key management and that EKR might have some good ideas on the subject. But thats _future_ work. Thank you. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 hardware that has just been deployed. * It is some old hardware that has suffered a factory reset. Here old means greater than two months - the root 5011 rollover period. When a validator is bootstrapping it needs to be able to tell the difference between an attack and a rolled TA. If it cannot get the new TA using the DNS, it must do so using some higher level protocol. Higher level protocols depend on the DNS. This implies that the system must provisionally switch off its validator in order to obtain a new TA. This implies that bootstrapping systems are vulnerable to downgrade attacks and therefore spoofing. Tony. -- f.anthony.n.finch d...@dotat.at 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 to focus on the document at hand, here. If you would like more insight into the design decisions that resulted in the current DPS, I am sure the authors of it would be happy to talk to you about it. There seems to be a significant difference between 5011 and the root TA operational plan. 5011 suggests there should be a backup TA key pair which is generated and published well in advance, but not used operationally. It just exists to be ready in case of loss or compromise of the operational TA. The root TA has no such backup. Correct. There is no hot-standby replacement KSK for the root zone. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 whether you expect RFC 5011 to work in the event of a compromise. It says: As part of the KSK emergency roll-over procedures, ICANN maintains the capability of being able to generate and publish an interim Trust Anchor within 48 hours. In favorable circumstances, this interim Trust Anchor may be used to facilitate an orderly RFC 5011 [RFC5011] automatic KSK roll-over to a new and sanctioned Trust Anchor generated at a new scheduled key ceremony held with reasonable time notice. Does that mean you'll use 5011 to roll from the interim TA to the sanctioned TA, but that validator operators will have to manually install the interim TA? Correct. jakob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 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 accurate. How do you figure that? I can put an entry in /etc/hosts (do this all the time for testing) and DNS isn't even queried. Yet the server certificate is validated as usual. But keep in mind that few TLS clients (such as browsers), currently support pinning of PKIX-authenticated server certs, so that on future connects only the very same server cert (with user-authenticated attributes other than DNS f.q.d.n) will be accepted from that server. In is very common misbehaviour in TLS clients to accept arbitrary other server certs on future connects, as long as the DNS f.q.d.n matches. Is there a spec saying this is invalid behavior? 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. If you're going to trust certs you get out of DNS, you might as well just put a self-signed organizational CA cert in there. Maybe that's what's being proposed. Say, what's the link to the Internet Draft proposal we're discussing anyway? - Marsh ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 (either in this DNSSEC context or more generally, but I'm concentrating on the DNSSEC context just now). On the one hand, we can understand keys as expressing a certain trustworthiness-assurance on the part of the key publisher. We can understand the publication of the key as an assertion on the part of the publisher that data signed with that key is trustworthy. I call this view publisher-centric. If we understand keys according to this scheme, then it is entirely reasonable for a key publisher to say, Once I have pulled a key, don't use it, ever. On the other hand, we can understand keys as a feature a publisher offers users in order that those users may make intelligent choices about trust. In this view, we can understand the publication of a key as part of that support offered to users who want to validate data. Those users are then in a position to make evaluations of data they receive. I call this the user-interpretive view. Under this view, it is not reasonable for a key publisher to try to prescribe how the key is to be used once it is published. This approach, however, comes with the risk to the user that the user will not know of a key compromise. The problem in this case is that the use-value to the user, which lies in increased confidence in the value of the signed data, is misplaced. Instead, the publisher's role is reduced to warning users (by policies) what uses the publisher is willing to support, and what uses are unsupported. It seems to me that both perspectives are useful and valuable, but they're different ways of looking at the issue and they have different implications. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 respond to Phillip's message, first go to keyassure mailing list archive[1], then join the the list[2] and comment there. I don't think we want to fill our inboxes with this discussion (which should really happen in keyassure) in several copies. While we value input from other working groups it is already hard to follow the discussion in one mailing list and when it splits to many, it will be just a mess. Ondrej 1. http://www.ietf.org/mail-archive/web/keyassure/ 2. https://www.ietf.org/mailman/listinfo/keyassure On 1.10.2010 17:29, Phillip Hallam-Baker wrote: For the past month I have been participating in the KEYASSURE discussions. One aspect of those discussions that was not made clear in the original notice sent out is that the group is not only considering key assurance, the proposals made are also intended to have security policy semantics. This was not apparent to me from reading the list announcement, the initial proposed charter or the Internet drafts. I have asked the organizers of the group to clarify the matter in the wider IETF community but they have not done so. In particular I am very concerned about the particular approach being taken to security policy. What the proposers are attempting to do is to create a mechanism that allows a site that only uses one particular high assurance CA to 'protect' themselves against SSL certificates being issued by low assurance CAs. As such, this is an objective I approve of and is one that I would like to see supported in a generalized security policy. It should be possible for a site to make security policy statements of the form 'all valid PKIX certs for example.com http://example.com have cert X in the validation path'. What I object to is the approach being taken which is to use DNSSEC to replace PKIX certificate validation entirely. Now the proponents are trying to downplay this by saying that 'all' they are doing is to tell people to 'ignore' PKIX validation. But that approach really offends my sense of layering. Worse still, the proponents refuse to allow any method of shutting this system off. So if I have a site where I want to use DNSSEC validated certificates on the mail server, deployment is going to impact my Web server. Specifically the proposal amounts to using the DNS CERT record to publish a fingerprint of all the certificates permitted for use with TLS at a specific domain: example.com http://example.com CERT TLSFP 0 0 digest cert 1 example.com http://example.com CERT TLSFP 0 0 digest cert 2 It is proposed to replace current TLS certificate processing semantics with the following: 1) Query for CERT record at example.com http://example.com 2) If no CERT record with TLSFP certificate type exists then perform normal PKIX validation and return that result 3) Otherwise attempt to match the TLS end entity certificate with one of the fingerprints specified in the published TLSFP RRs 4) If a match is found return VALID, otherwise return INVALID Note here that if there is a TLSFP RR that it takes precedence over PKIX processing rules. There should of course be DNSSEC validation performed in that process as well, but the authors have not explained how that is meant to work in the context of their proposal so I left it out. The defenses made for this approach are of the form 'you have to wear big pants to play this game'. In other words if people are going to administer these systems and not be burned they are going to have to understand what they are doing. I do not consider this a responsible approach to protocol design. What I would prefer is to have systems that do not need to be administered by people at all. That is not possible when the approach has hidden side effects that cannot be anticipated by scripts. I am very much committed to the idea of doing security policy. But this is not an approach I can support. Any policy mechanism has to be orthogonal to the key validation strategy in my view. I should be able to use any DNS security policy mechanism that the IETF endorses with PKIX certificate processing semantics. I have proposed an alternative approach in http://tools.ietf.org/html/draft-hallambaker-esrv-00 This does not currently contain a mechanism to express trust restrictions but is designed to be extensible to support such. When I proposed ESRV I was unaware that the KEYASSURE proposal was intended to have a security policy aspect at all. It is still not made explicit in their draft. Using the revised version of ESRV I am currently writing, a security policy of the form 'always use TLS with any protocol at example.com http://example.com' would have the form: example.com http://example.com ESRV
Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt
On 4 Oct 2010, at 16:34, Joe Abley jab...@hopcount.ca 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 discussion of the KSK DPS. I would prefer to focus on the document at hand, here. It is relevant because the trust anchor publication scheme is the only fallback we have when RFC 5011 fails. If we can reduce the number of possible failure scenarios then we don't have to rely so much on higher level systems that are less well documented and not so impressively well secured. I am really concerned that it might become impossible to roll the root TA. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ If you would like more insight into the design decisions that resulted in the current DPS, I am sure the authors of it would be happy to talk to you about it. There seems to be a significant difference between 5011 and the root TA operational plan. 5011 suggests there should be a backup TA key pair which is generated and published well in advance, but not used operationally. It just exists to be ready in case of loss or compromise of the operational TA. The root TA has no such backup. Correct. There is no hot-standby replacement KSK for the root zone. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 bootstraps itself at day zero. I expect that validators will ship with an initial TA built in (e.g. as BIND does for DLV) which means the two scenarios are very different. Even if the validator does not ship with an initial TA, there is still a big difference between no TA and a broken TA, so the validator still has to be able to work out if the breakage is benign or malicious. It would be nice to see some evidence that other people are thinking about this problem seriously and in detail rather than brushing off my questions :-/ Tony. -- f.anthony.n.finch d...@dotat.at 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 compromised do things go horribly wrong. Tony. -- f.anthony.n.finch d...@dotat.at 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 here, but this came up in the W3C WSC work and I wrote up an idea for that (not based on DNS) which is RFC 5697. [1] No idea if anyone is using or would use it, though I did have a student implement it, so it *could* work. (Note: that's an experimental-track RFC, as it ought be:-) S. [1] http://tools.ietf.org/html/rfc5697 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 accurate. How do you figure that? I can put an entry in /etc/hosts (do this all the time for testing) and DNS isn't even queried. Yet the server certificate is validated as usual. In order to get a TLS server cert issued for a particular DNS f.q.d.n under most of the existing pre-configured trust anchors, you only need to provide some vague proof that you leased that DNS domain. The no-prompt server endpoint identification will ignore any information in the cert besides the DNS f.q.d.n, no matter how carefully that other part of information may be validated. But keep in mind that few TLS clients (such as browsers), currently support pinning of PKIX-authenticated server certs, so that on future connects only the very same server cert (with user-authenticated attributes other than DNS f.q.d.n) will be accepted from that server. In is very common misbehaviour in TLS clients to accept arbitrary other server certs on future connects, as long as the DNS f.q.d.n matches. Is there a spec saying this is invalid behavior? No. For the existing specs, this issue fell into the huge out-of-scope gaps between rfc-2818, PKIX and TLS. I know there is a school of thought popular in the US that is build around but it didn't come with a warning label that I must not shoot in my foot, so it isn't my fault. I assume that _very_ few of those TLS-enabled servers that offer TLS client cert authentication, base their authorization decision on only one particular certificate attribute and ignore all the rest of the certificate and allow it to chain to arbitrary CAs operated under any one of 100 pre-configured trust anchors. But for the server side, no-prompting usability has always been deemed MUCH more important than security. 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. If you're going to trust certs you get out of DNS, you might as well just put a self-signed organizational CA cert in there. Maybe that's what's being proposed. That only affects the frequency of the key/cert rollover, not the fact that key/cert rollover needs to be addressed. Distributing an organizations CA cert through DNS instead of the server certs is somewhat incompatible with how a lot of traditional PKI software works (like Microsoft's CryptoAPI on XP/2003). PKIX specs define certificate path validation only when you have a certificate chain to one of your trust anchors. You probably will _NOT_ want most of these CAs a trust anchor, even when you might allow the use of such organizational CA certs for verification of specific server certificates. I once received an S/Mime signed Email in Outlook 2003, and the signature included an end-entity and an intermediateCA cert. I found myself unable to make Outlook verify the digital signature of that Email, because of a lack of the (non-public, organizational) RootCA cert for that chain. Say, what's the link to the Internet Draft proposal we're discussing anyway? To me it sounded like it is a post-prototype implementation, pre-draft discussion about the charter of the keyassurance WG. -Martin ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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. Only if both of them are simultaneously lost or compromised do things go horribly wrong. I hear you, but there is no backup KSK in the sense that I think you mean (there is no pre-generated, hot-standby incoming KSK). Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 KSK. You handle key compromises in exactly the same way. (This implies you ahould have diverse systems and storage for the live and backup keys.) nor is it very useful if the algorithm used for the active KSK is compromised. There isn't a very good solution for that since DNSSEC requires that a zone has RRSIGs for all algorithms for which it has DNSKEYs, so you can't pre-publish an inactive SEP key with a different algorithm. We just have to hope that algorithms are broken slowly, like MD5 :-) Tony. -- f.anthony.n.finch d...@dotat.at 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 its DNSSEC validator? The same way that it bootstraps itself at day zero. I expect that validators will ship with an initial TA built in (e.g. as BIND does for DLV) which means the two scenarios are very different. We've talked to DNS vendors and although I don't want to foreshadow their timelines for making code or strategies available, I can tell you that there is work underway to accommodate 5011 rollover, 5011 rollover with a client that is disconnected over the transition window, and day-zero trust anchor bootstrap. No show-stoppers have been identified in the conversations I have seen. No doubt the vendors concerned will describe their approach when they are ready. Even if the validator does not ship with an initial TA, there is still a big difference between no TA and a broken TA, so the validator still has to be able to work out if the breakage is benign or malicious. It would be nice to see some evidence that other people are thinking about this problem seriously and in detail rather than brushing off my questions :-/ I think some of your questions are best directed towards vendors. 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. The DPS is not written in concrete, but at the same time we are not about to make radical changes in a split second now that the key is in production. We are being audited against the current DPS, as-published. I think also that there is some sense that the trust-anchor document is intended as a starting point for a working group design exercise, which is not the case. This is an informational document describing an existing service, and is being published in the interests of having a stable specification in a sensible place for vendors to code against. We are not seeking working group adoption; our goal is an AD-sponsored, individual submission. Hence the review here is really in the interests of document quality and clarity of the specification (something that many reviewers have helped us with already, and which I expect will result in a better document). Really, I'm not trying to brush off your questions, but given the context above it's difficult to give you the kind of answers you seem to want. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 don't. I meant that the emergency rollover scenarios described in 5011 expect you to have one. Tony. -- f.anthony.n.finch d...@dotat.at 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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. Also, DNSSEC doesn't protect from IP hijacking (re-routing). PKIX provides a secure association TO/FROM a name to a public key. The host owner holds the private key and can prove ownership of the related public key. But the host owner tends not to be the domain owner so the asserted association may not reflect the intent of the DNS domain owner. What if - the PKIX certificate for the host contained a permit for the name signed by the DNS owner? A signature over the hash of the public key in the certificate, and the DNS name - and maybe some expiration info verifiable by the data in DNSSEC? The path goes something like: 1) Use DNS and DNSSEC to find the host (or even just DNS) 2) Use TLS to grab the certificate 3) Verify the certificate using the PKIX path to a trust anchor 4) Verify the host knows the private key related to the host certificate 5) Verify the extension in the certificate was signed by the domain's DNSSEC key (pick one of special key, KSK or ZSK) 6) Verify the name offered in the certificate matches the DNS name looked up. You've verified that: a) The zone owner has assigned the name to the owner of the cert's private key b) The host owner has agreed the host has the DNS name. c) The IP to Name mapping (what might be in the PTR record and signed under DNSSEC - maybe). The DNSSEC name to IP address mapping becomes irrelevant for trust purposes which means that IP hijacking is no longer an issue. A random PKIX forming a certificate with a DNS name in it can't form one that proves the name assignment from the DNS, so the large set of PKIX trust anchors becomes less of an issue. Mike ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 operational consideration that is orthogonal to the specification. I agree that there are circumstances where we might receive an unpleasant load of traffic. If that was to happen, we would deal with it, as ICANN's IT department deals with other such operational challenges. I can tell you that data.iana.org is currently being hosted on some sensibly-sized iron and I would expect it to accommodate substantial flash crowds, and that there is a full-time team of engineers that runs all ICANN's internal infrastructure, for what that's worth. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 decided that it was time to do so myself. My original understanding from the announcement made was that 'assurance' meant to provide additional mechanisms for binding keys to DNS names. It has since turned out that what is being proposed is very different and has significant impact across the whole IETF security area. My problem with KEYASSURE is precisely the fact that people have not been given the 'full picture'. Even now after three drafts, the key-linkage draft does not actualy specify that the purpose of the protocol is to enable a site to specify which certificates are valid for the site by enumeration of all valid certs. That is merely an unremarked consequence of the algorithm. 2010/10/4 Ondřej Surý ondrej.s...@nic.cz 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 respond to Phillip's message, first go to keyassure mailing list archive[1], then join the the list[2] and comment there. I don't think we want to fill our inboxes with this discussion (which should really happen in keyassure) in several copies. While we value input from other working groups it is already hard to follow the discussion in one mailing list and when it splits to many, it will be just a mess. Ondrej 1. http://www.ietf.org/mail-archive/web/keyassure/ 2. https://www.ietf.org/mailman/listinfo/keyassure On 1.10.2010 17:29, Phillip Hallam-Baker wrote: For the past month I have been participating in the KEYASSURE discussions. One aspect of those discussions that was not made clear in the original notice sent out is that the group is not only considering key assurance, the proposals made are also intended to have security policy semantics. This was not apparent to me from reading the list announcement, the initial proposed charter or the Internet drafts. I have asked the organizers of the group to clarify the matter in the wider IETF community but they have not done so. In particular I am very concerned about the particular approach being taken to security policy. What the proposers are attempting to do is to create a mechanism that allows a site that only uses one particular high assurance CA to 'protect' themselves against SSL certificates being issued by low assurance CAs. As such, this is an objective I approve of and is one that I would like to see supported in a generalized security policy. It should be possible for a site to make security policy statements of the form 'all valid PKIX certs for example.com http://example.com have cert X in the validation path'. What I object to is the approach being taken which is to use DNSSEC to replace PKIX certificate validation entirely. Now the proponents are trying to downplay this by saying that 'all' they are doing is to tell people to 'ignore' PKIX validation. But that approach really offends my sense of layering. Worse still, the proponents refuse to allow any method of shutting this system off. So if I have a site where I want to use DNSSEC validated certificates on the mail server, deployment is going to impact my Web server. Specifically the proposal amounts to using the DNS CERT record to publish a fingerprint of all the certificates permitted for use with TLS at a specific domain: example.com http://example.com CERT TLSFP 0 0 digest cert 1 example.com http://example.com CERT TLSFP 0 0 digest cert 2 It is proposed to replace current TLS certificate processing semantics with the following: 1) Query for CERT record at example.com http://example.com 2) If no CERT record with TLSFP certificate type exists then perform normal PKIX validation and return that result 3) Otherwise attempt to match the TLS end entity certificate with one of the fingerprints specified in the published TLSFP RRs 4) If a match is found return VALID, otherwise return INVALID Note here that if there is a TLSFP RR that it takes precedence over PKIX processing rules. There should of course be DNSSEC validation performed in that process as well, but the authors have not explained how that is meant to work in the context of their proposal so I left it out. The defenses made for this approach are of the form 'you have to wear big pants to play this game'. In other words if people are going to administer these systems and not be burned they are going to have to understand what they are doing. I do not consider this a responsible approach to protocol design. What I would prefer is
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 designed by people who claim not to understand the issues involved. As the proposers of this scheme have done repeatedly. Suppose all of that is true (and I think it's a gross misrepresentation of the situation, but never mind that), so what? Presumably, if this new PKI sucks as much as you say it does, nobody will use it, and no harm will come. If it's a kind of snake oil that appeals to the clueless (i.e. it sucks as much as you say it does, but it's jumped up and marketed in a way that lures people who don't know any better), then it will have some spectacular failure and everyone will thenceforth avoid it. So what's the problem, even if things are as bad as you say? Also, why isn't this on the list devoted to this discussion (followup set)? A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC
Lots of statements concerning how CAs work 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 low quality. Which is why I would like to see the padlock icon phased out entirely. Why does the user need to know if encryption is being used at all? Actually the reason the user need to know that encryption is being used is quite an interesting one and has to do with the lack of a security policy layer for the Internet. If we could guarantee that encryption would always be used when visiting a site where there is a certificate, there would be no need for the padlock icon. But that is a digression. The problem raised by many people here is that a site example.com can get an SSL certificate with the highest available assurance level but a MITM attack can be performed with a low assurance certificate obtained from any of the CAs listed in the browser roots. There are two possible means of attacking this problem 1) Provide a means for determining if a certificate is authorized for use 2) Sanction CAs that issue unauthorized certificates The TLSFP approach only allows the first approach to be employed. My approach, publication of the authorized CA roots permits both approaches to be employed. The way I see this working is that each CA would publish a record that customers could publish in their DNS zone to state that other CAs should not issue certs. This would have the Digest of either the root key or an intermediate cert. example.com ESRV pkix=29823dhd2w3298yf2== Some sites might have multiple roots advertised for cases where they are switching providers: example.com ESRV pkix=29823dhd2w3298yf2== pkix=2u2queihwiehiuhe== And there could also be provision for advertising CERT records and so on. We can fill in those details later. Once the necessary record is allocated, a proposal is made to CABForum to require all member CAs to verify every cert against these DNS records before issue. I believe that there should be a very high degree of voluntary compliance since it is a check that can be automated. After a short interval the mechanism is made mandatory. The browser and platform providers have the necessary tools to achieve this. They can require the checks to be specified in the annual WebTrust audit which means that every cert would have to be in compliance within a year. Non compliant certificates would be detected as a matter of course by the various companies who have reason to crawl the Web and look at SSL certs. Note that my approach does not require client implementation to be effective, but allows for client implementation if this is considered desirable and is equally effective as a means of client side enforcement. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 transition/rollover. Maybe a side-issue here, but this came up in the W3C WSC work and I wrote up an idea for that (not based on DNS) which is RFC 5697. [1] No idea if anyone is using or would use it, though I did have a student implement it, so it *could* work. (Note: that's an experimental-track RFC, as it ought be:-) S. [1] http://tools.ietf.org/html/rfc5697 I do _not_ like the OtherCertificates extension. If some client would honour this for a pinned cert, it would allow an arbitrary CA under any of the trusted roots to completely subvert the clients motivation of pinning the cert. A sensible approach would require a certificate extension in the new cert which provides a proof from the original certificate holder (i.e. signed with the private key of the old cert), that the new cert (the public key and at least some of the certificat attributes, such as subject name, all subjectAltNames, BasicConstraints, keyUsage, ExtendedKeyUsage, maybe more) are a valid replacement for the original server cert. Key continuity without the consent of the original key holder looks dangerous to me. -Martin ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
