Re: Is cryptography where security took the wrong branch?

2003-09-10 Thread bmanning
 
 At 03:39 AM 9/10/2003 -0700, [EMAIL PROTECTED] wrote:
  There are some other problems w/ using the DNS.
  No revolkation process.
  DNS caching
  third-party trust (DNS admins != delegation holder)
 
 Given high value /or low trust ... relying parties still have option of 
 directly contacting root authority. And as outline, the root authority is 
 also the root authority for the CA/PKIs. If you attack the root trust 
 authority with false information  then all subsequent trust operations 
 flowing from that false information is suspect. Domain name system still 
 has some exploits against the root database resulting in false information 
  but since that is the root for both DNS as well as CA/PKIs generating 
 SSL domain name certificates  it is a common failure point for both 
 infrastructures. It needs to be fixed, in order to improve trust on either 
 the DNS side or the CA/PKI side (doesn't matter how thick you make the 
 vault door  if somebody forgot to complete the back wall on the vault).

ok...  does anyone else want to touch a secured DNS system
that has some parts fo the tree fully signed?  Its a way to 
get some emperical understanding of how interesting/hard
it is to hammer the DNS into a PKI-like thing.

www.rs.net  has some information.

 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
 


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: A Note About Trust Anchor Key Distribution

2005-07-08 Thread bmanning

nice paper.  note that it claims this paper is being published to 
establish IPR claims.  there is prior art in several vectors.

you may wish to consider the following (although now expired) 
Internet Drafts:

draft-ietf-dnsext-trustupdate-threshold-00

and a similar one authored by Mike StJohns.

that cover the same basic ideas. at least one of
these is being updated and revised.

--bill manning

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Exponent 3 damage spreads...

2006-09-10 Thread bmanning
On Sun, Sep 10, 2006 at 08:30:53AM +1000, James A. Donald wrote:
 --
 Ben Laurie wrote:
  Subject:
  [dnsop] BIND and OpenSSL's RSA signature forging issue
  From:
  Ben Laurie [EMAIL PROTECTED]
  Date:
  Fri, 08 Sep 2006 11:40:44 +0100
  To:
  DNSEXT WG namedroppers@ops.ietf.org, (DNSSEC deployment)
  [EMAIL PROTECTED], dnsop@lists.uoregon.edu
 
  To:
  DNSEXT WG namedroppers@ops.ietf.org, (DNSSEC deployment)
  [EMAIL PROTECTED], dnsop@lists.uoregon.edu
 
 
  I've just noticed that BIND is vulnerable to:
 
  http://www.openssl.org/news/secadv_20060905.txt
 
  Executive summary:
 
  RRSIGs can be forged if your RSA key has exponent 3, which is BIND's
  default. Note that the issue is in the resolver, not the server.
 
  Fix:
 
  Upgrade OpenSSL.
 
  Issue:
 
  Since I've been told often that most of the world won't upgrade
  resolvers, presumably most of the world will be vulnerable to this
  problem for a long time.
 
  Solution:
 
  Don't use exponent 3 anymore. This can, of course, be done server-side,
  where the responsible citizens live, allegedly.
 
  Side benefit:
 
  You all get to test emergency key roll! Start your motors, gentlemen!
 
 This seems to presuppose that Secure DNS is actually in use.  I was 
 unaware that this is the case.
 
 What is the penetration of Secure DNS?

hard to tell... how many delegations are there?
that said, RIPE has signed all their delegations
and the SE delegation is signed.  privately, i am
aware of perhaps a dozen or so other delegations 
which are signed.  one might also look to the ISC
DLV registry to see which of those delegations are
signed.

--bill
 
 
 --digsig
  James A. Donald
  6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
  fLselD6l8fdbF1p4sjg3RQ2GXi+NnQ//1CymnfKs
  4+JAX1zwW3fSIStp6glgbAygK1zCuoMeiTigr4qmd
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: How is DNSSEC

2008-03-21 Thread bmanning
On Fri, Mar 21, 2008 at 08:52:07AM +1000, James A. Donald wrote:
 From time to time I hear that DNSSEC is working fine, and on examining 
 the matter I find it is working fine except that 
 
 Seems to me that if DNSSEC is actually working fine, I should be able to 
 provide an authoritative public key for any domain name I control, and 
 should be able to obtain such keys for other domain names, and use such 
 keys for any purpose, not just those purposes envisaged in the DNSSEC 
 specification.  Can I?  It is not apparent to me that I can.


actually, the DNSSEC specification -used- to support 
keys for any purpose, and in theory you could use
DNSSEC keys in that manner.  However a bit of careful
thought suggests that there is potential  disconnect btwn
the zone owner/admin who creates/distributes the keys as 
a token of the integrity and authenticity of the data in
the DNS, and the owner/admin of the node to which the DNS
data points.  Remember that while you may control your forward
name (and not many people actually run their own DNS servers)
it is less likely that you run your address maps - and for
the paranoid, you would want to ensure the forward and 
reverse zones are signed and at the intersection, there is
a common data element which you can use.

To do what you want, want, you might consider using the
CERT-rr, using the DNS to distribute host-specific keys/certs.
And to ensure that the data in the DNS was not tampered with,
using DNSSEC signed zones with CERT-rr's would not be a bad
thing.   In fact, thats what we are testing .

 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: How is DNSSEC

2008-03-26 Thread bmanning
On Sat, Mar 22, 2008 at 10:59:18AM +, Ben Laurie wrote:
 [EMAIL PROTECTED] wrote:
 On Fri, Mar 21, 2008 at 08:52:07AM +1000, James A. Donald wrote:
 From time to time I hear that DNSSEC is working fine, and on examining 
 the matter I find it is working fine except that 
 
 Seems to me that if DNSSEC is actually working fine, I should be able to 
 provide an authoritative public key for any domain name I control, and 
 should be able to obtain such keys for other domain names, and use such 
 keys for any purpose, not just those purposes envisaged in the DNSSEC 
 specification.  Can I?  It is not apparent to me that I can.
 
 
  actually, the DNSSEC specification -used- to support 
  keys for any purpose, and in theory you could use
  DNSSEC keys in that manner.  However a bit of careful
  thought suggests that there is potential  disconnect btwn
  the zone owner/admin who creates/distributes the keys as 
  a token of the integrity and authenticity of the data in
  the DNS, and the owner/admin of the node to which the DNS
  data points.
 
 So far, so good. This disconnect doesn't seem to have done the CA 
 industry any harm, though.

The CA business -is- to serve as a notary They attest to
the binding o fthe key to holder.  To date, thats NOT what
a zone admin does, he is attesting that its HIS key, that it
is HIS record in HIS database.  Just because he has sold the
right to use to someone else, is still his database and his data.

Unless of course Nominet (for example) is now going to allow 
client driven dynamic updates - where the clients are in complete 
control of their data.  (thats closer to James, assertion that he 
owns/controls his domain name)

 
   Remember that while you may control your forward
  name (and not many people actually run their own DNS servers)
  it is less likely that you run your address maps - and for
  the paranoid, you would want to ensure the forward and 
  reverse zones are signed and at the intersection, there is
  a common data element which you can use.
 
 Non sequiteur, plus I can't see why paranoia would prompt me to want to 
 do this? What does it prove?

The argument is, again, to James asserton that he owns his domain 
name.  In point of fact, every node has at least two names
in the DNS, the forward (which gets most of the attention) and the
reverse - which is nearly always controled by your ISP.

DNSSEC validation along one path in the DNS graph is reassuring
(or so it is claimed).  I posit that validation over two, generally
non-overlapping administrative spheres of influence, in the DNS
graph would give a higher level of assurance. Couple this with
finding the identical x509 cert at the origin of the validation
chain for both paths - and I think I have a much higher confidence
that I am actually going to be sending packets to the right
node.


 Also, PTR records are only supposed to point to primary domain names. 
 Since it is common for hosts to have many names resolving to the same IP 
 address, by definition most of these will not correspond to the reverse 
 lookup.

Er... Allow me the option o fdisbeleiving your assertion.
PTR records can and do point to mutiple names.  Some narrow
implementations have assumed that there will only be a single
data element and this myth - that PTRs only point to a single
name - is and has been spread widely.

  To do what you want, want, you might consider using the
  CERT-rr, using the DNS to distribute host-specific keys/certs.
  And to ensure that the data in the DNS was not tampered with,
  using DNSSEC signed zones with CERT-rr's would not be a bad
  thing.   In fact, thats what we are testing .
 
 Who is we and what exactly are you testing?

We is USMIR, the registry for .UM  -  www.nic.um

--bill

 
 Cheers,
 
 Ben.
 
 -- 
 http://www.apache-ssl.org/ben.html   http://www.links.org/
 
 There is no limit to what a man can do or how far he can go if he
 doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: [mm] How is DNSSEC

2008-03-26 Thread bmanning
On Sat, Mar 22, 2008 at 02:46:40PM +, Ben Laurie wrote:
 [EMAIL PROTECTED] wrote:
  Er... Allow me the option o fdisbeleiving your assertion.
  PTR records can and do point to mutiple names.  Some narrow
  implementations have assumed that there will only be a single
  data element and this myth - that PTRs only point to a single
  name - is and has been spread widely.
 
 You can disbelieve my assertion if you wish, but I am only quoting the 
 RFC. RFC 1035, to be precise:
 
 Address nodes are used to hold pointers to primary host names
 in the normal domain space.
 
 (section 3.5. IN-ADDR.ARPA domain). So, the myth is in the scripture.


ah... open to interpretation.  what is a primary host name?

--bill

 
 -- 
 http://www.apache-ssl.org/ben.html   http://www.links.org/
 
 There is no limit to what a man can do or how far he can go if he
 doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


unintended?

2008-11-14 Thread bmanning
(snicker)  from the local firefox


en-us.add-ons.mozilla.com:443 uses an invalid security certificate.

The certificate is not trusted because the issuer certificate is not trusted.

(Error code: sec_error_untrusted_issuer)




--bill

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: unintended?

2008-11-17 Thread bmanning
On Fri, Nov 14, 2008 at 02:29:24PM -0700, Chad Perrin wrote:
 On Fri, Nov 14, 2008 at 01:26:29PM +, [EMAIL PROTECTED] wrote:
  (snicker)  from the local firefox
  
  
  en-us.add-ons.mozilla.com:443 uses an invalid security certificate.
  
  The certificate is not trusted because the issuer certificate is not 
  trusted.
  
  (Error code: sec_error_untrusted_issuer)
 
 What does Perspectives have to say?
 
 What installation of Firefox did you use?
 
 I don't have that problem when I visit:
   https://addons.mozilla.org/en-US/firefox/
 
 Do you perhaps have some kind of malicious redirection going on there?
 
 -- 
 Chad Perrin [ content licensed PDL: http://pdl.apotheon.org ]


perspectives is not installed.  I've never taken the default and
added a cert that was not in the firefox trusted list... (at least on
a permanent basis)


Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.2) 
Gecko/2008091618 Firefox/3.0.2

and yes, a redirect might be in play - except this happens w/ multiple, 
different caches
(fm the house, work, panera, starbucks and even the cows end)

--bill

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Possibly questionable security decisions in DNS root management

2009-10-14 Thread bmanning
On Wed, Oct 14, 2009 at 06:24:06PM -0400, Perry E. Metzger wrote:
 
 Ekr has a very good blog posting on what seems like a bad security
 decision being made by Verisign on management of the DNS root key.
 
 http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html
 
 In summary, a decision is being made to use a short lived 1024 bit key
 for the signature because longer keys would result in excessively large
 DNS packets. However, such short keys are very likely crackable in short
 periods of time if the stakes are high enough -- and few keys in
 existence are this valuable.


however - the VSGN proposal meets current NIST guidelines.

--bill


 
 Perry
 -- 
 Perry E. Metzger  pe...@piermont.com
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Possibly questionable security decisions in DNS root management

2009-10-14 Thread bmanning
On Wed, Oct 14, 2009 at 07:22:27PM -0400, Perry E. Metzger wrote:
 
 bmann...@vacation.karoshi.com writes:
  On Wed, Oct 14, 2009 at 06:24:06PM -0400, Perry E. Metzger wrote:
  Ekr has a very good blog posting on what seems like a bad security
  decision being made by Verisign on management of the DNS root key.
 
  http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html
 
  In summary, a decision is being made to use a short lived 1024 bit key
  for the signature because longer keys would result in excessively large
  DNS packets. However, such short keys are very likely crackable in short
  periods of time if the stakes are high enough -- and few keys in
  existence are this valuable.
 
  however - the VSGN proposal meets current NIST guidelines.
 
 That doesn't say anything about how good an idea it is, any more than an
 architect can make a building remain standing in an earthquake by
 invoking the construction code.
 
 We are the sort of people who write these sorts of guidelines, and if
 they're flawed, we can't use them as a justification for designs.
 
 (Well, a bureaucrat certainly can use such documents as a form of CYA,
 but we're discussing technology here, not means of evading blame.)
 
 The fact is, the DNS root key is one of the few instances where it is
 actually worth someone's time to crack a key because it provides
 enormous opportunities for mischief, especially if people start trusting
 it more because it is authenticated. Unlike your https session to view
 your calendar or the password for your home router, the secret involved
 here are worth an insane amount of money.


er... there is the root key and there is the ROOT KEY.
the zsk only has a 90 day validity period.  ... meets the
spec and -ought- to be good enough.   that said, it is
currently a -proposal- and if credible arguments can be made
to modify the proposal, I'm persuaded that VSGN will do so.



 Perry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Possibly questionable security decisions in DNS root management

2009-10-20 Thread bmanning
On Tue, Oct 20, 2009 at 09:20:04AM -0400, William Allen Simpson wrote:
 Nicolas Williams wrote:
 Getting DNSSEC deployed with sufficiently large KSKs should be priority #1.
 
 I agree.  Let's get something deployed, as that will lead to testing.
 
 
 If 90 days for the 1024-bit ZSKs is too long, that can always be
 reduced, or the ZSK keylength be increased -- we too can squeeze factors
 of 10 from various places.  In the early days of DNSSEC deployment the
 opportunities for causing damage by breaking a ZSK will be relatively
 meager.  We have time to get this right; this issue does not strike me
 as urgent.
 
 One of the things that bother me with the latest presentation is that
 only dummy keys will be used.  That makes no sense to me!  We'll have
 folks that get used to hitting the Ignore key on their browsers
 
 http://nanog.org/meetings/nanog47/presentations/Lightning/Abley_light_N47.pdf


the use of dummy keys in the first round is to test things like 
key rollover - the inital keys themselves are unable to be validated
and state as much.  Anyone who tries validation is -NOT- reading 
the key or the deployment plan.

 
 Thus, I'm not sure we have time to get this right.  We need good keys, so
 that user processes can be tested.

next phase.
 
 
 OTOH, will we be able to detect breaks?  A clever attacker will use
 breaks in very subtle ways.  A ZSK break would be bad, but something
 that could be dealt with, *if* we knew it'd happened.  The potential
 difficulty of detecting attacks is probably the best reason for seeking
 stronger keys well ahead of time.
 
 Agreed.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Fw: Root Zone DNSSEC Deployment Technical Status Update

2010-07-18 Thread bmanning
On Sat, Jul 17, 2010 at 10:41:10AM -0400, Paul Wouters wrote:
 On Fri, 16 Jul 2010, Taral wrote:
 
 Neat, but not (yet) useful... only these TLDs have DS records:
 
 The rest will follow soon. And it is not that you had to stop those
 TLD trust anchors just now.


actually, soon is a relative term.  Some have stated they are
waiting for operational issues to settle before they proceed.
could be a few months, could be a few years.

 
 Several are using old SHA-1 hashes...
 
 old ?

:) really old.
 
 Paul
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)

2010-08-23 Thread bmanning
On Sun, Aug 22, 2010 at 11:51:01AM -0400, Anne  Lynn Wheeler wrote:
 On 08/22/2010 06:56 AM, Jakob Schlyter wrote:
 There are a lot of work going on in this area, including how to use secure 
 DNS to
 associate the key that appears in a TLS server's certificate with the the 
 intended
 domain name [1]. Adding HSTS to this mix does make sense and is something 
 that is
 discussed, e.g. on the keyassure mailing list [2].
 
 There is large vested interested in Certification Authority industry
 selling SSL domain name certificates. A secure DNS scenario is having
 a public key registered at the time the domain name is registered ...
 and then a different kind of TLS ... where the public key is returned
 in piggy-back with the domain name to ip-address mapping response.


for the conservative - they may want to verify the DNSSEC
trust chains for both the domain name and the IP address.

e.g. is it the same EV cert at the end of both validation
checks.

--bill

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


[Cryptography] soft chewy center

2013-09-10 Thread bmanning

much of the discussion these past few weeks seems to be centered on channel and 
container 
protection, secure paths,  encrypted file systems, etc.  much effort has gone 
into ensureing
opaque environments for data to flow.   and while interesting and perhaps 
useful, not a whole lot 
of effort seems to targeting the integrity of the data itself. wrapping the 
soft chewy middle
with a hard candy shell can and does hide the fact that your core/data may be 
rotten.

some years back, i was part of a debate on the relative value of crypto - and 
it was pointed
out that for some sectors,  crypto ensured _failure_ simply because processing 
the bits introduced
latency.  for these sectors, speed was paramount.

think HFT or any sort of Flash Mob event where you want in/out as quickly as 
possible.  

crypto in and of itself is not a generator of value. Sprinkeling 
Security/Crypto pixie dust
on -everything- can not be a good idea.   

Just my 0.02 lira.   Jari and Stephen, please don't take the IETF there - its a 
wasteland.

/bill
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography