On Sat, 21 Sep 2013, Dave Crocker wrote:
2) Encourage distributed services over centralized services. For
example, social networking services today are heavily centralized.
+1
Except that essentially all services other than email have gained popularity
in centralized form, including IM.
On Sat, 21 Sep 2013, Stephen Farrell wrote:
On 09/21/2013 02:42 PM, Roger Jørgensen wrote:
On Fri, Sep 20, 2013 at 6:54 AM, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
I got my arm slightly twisted to produce the attached: a simple
concatenation of some of the actionable suggestions
On Wed, 11 Sep 2013, Joe Abley wrote:
1. We only need to know the current time to an accuracy of 1 hour.
[RRSIG expiration times are specified with a granularity of a second, right?
I appreciate that most people are generous with signature inception and expiration times
in order to
On Thu, 12 Sep 2013, Theodore Ts'o wrote:
More importantly, what problem do people think DNSSEC is going to
solve?
It is still a hierarchical model of trust. So at the top, if you
don't trust Verisign for the .COM domain and PIR for the .ORG domain
(and for people who are worried about the
On Thu, 12 Sep 2013, Theodore Ts'o wrote:
Any co-ercing that happens has to be globally visible, if the target
ensures he is using random nameservers to query for data.
Not necessarily. First of all, an active attacker located close to
the target can simply replace the DNS replies with bogus
On Wed, 11 Sep 2013, Olafur Gudmundsson wrote:
I think you can avoid that issue by having the device not pass traffic
until the DNSSEC validation is enabled. Only the device needs the special
permissive handling for this to work.
You mean only allow NTP and DNS traffic in the beginning, until
On Tue, 10 Sep 2013, Jim Gettys wrote:
We uncovered two practical problems, both of which need to be solved to enable
full DNSSEC deployment into the home:
1) DNSSEC needs to have the time within one hour. But these devices do not
have TOY clocks (and arguably, never will, nor even probably
On Mon, 9 Sep 2013, Fernando Gont wrote:
It might be worth thinking about why ssh and ssl work so well, and
PGP/GPG don't.
Just a quick guess: SSL works automagically, PGP doesn't. So even if the
user doesn't care, SSL is there. PGP, OTOH, usually requires explicit
installation of a plug in
On Fri, 12 Jul 2013, Keith Moore wrote:
On 07/12/2013 09:28 AM, Phillip Hallam-Baker wrote:
On Fri, Jul 12, 2013 at 8:58 AM, Keith Moore mo...@network-heretics.com
wrote:
On 07/12/2013 08:16 AM, Phillip Hallam-Baker wrote:
And before people start bringing
On Fri, 12 Jul 2013, Paul Wouters wrote:
I clearly meant 192.168.1.1 to go to Keith Moore, but the terribly gmail
quoting method confused me in who said what :P
Paul
Date: Fri, 12 Jul 2013 10:12:24
From: Paul Wouters p...@nohats.ca
Cc: Phillip Hallam-Baker hal...@gmail.com,
IETF
On Fri, 12 Jul 2013, Phillip Hallam-Baker wrote:
Today most people have come to accept my position on NAT, in fact it has become
the mainstream position.
Or perhaps I was not. But I guess it's software written by those three
companies listed below that's soo good that makes quoting clear :P
On Fri, 12 Jul 2013, Phillip Hallam-Baker wrote:
I notice you are missing .oracle and .exchange and .mail. Is that
because you can't take any more slaps on the back or because you know
too many companies that have servers in their domain that would get
bypassed by your awesome magic three
Hugh Daniel passed away on June 3rd after what appears to have been a heart
attack.
https://nohats.ca/hugh-of-borg.jpg
Those who met him, know him. Principled to the core, and very present in
any room, he compelled people to listen to him - both by what he said,
and how loud he said it.
He
On Mon, 18 Mar 2013, alejandroacostaal...@gmail.com wrote:
I used to connect using a regular jabber client but the experience with
meetecho is much better. Having audio, chat room and the slides is fantastic.
I did not use the html5 version so my audio was using vlc, I had to modify our
On Sat, 9 Mar 2013, Warren Kumari wrote:
Is someone going to update the IETFers iphone app? It still does not
have the sculed in it :/
I have no idea, but this reminds me….
A huge, heartfelt thanks to whoever wrote it -- it makes life much much easier…
The IETF86 schedule updates when you
On Fri, 8 Mar 2013, Jari Arkko wrote:
The IETF meeting is beginning on Sunday. I'd like to welcome everyone to the
meeting! This blog highlights some of topics that I find most interesting in
the meeting:
http://www.ietf.org/blog/2013/03/welcome-to-ietf-86/
Is someone going to update the
On Mon, 26 Nov 2012, Benson Schliesser wrote:
I expect to be flamed for suggesting it, but why not use the Shared Address
Space for this purpose?
(http://tools.ietf.org/html/rfc6598)
You can't, if carriers are assigning you that IP range. You'd still get
a conflict if you use it for your own
On Sat, 24 Nov 2012, Sabahattin Gucukoglu wrote:
http://b.logme.in/2012/11/07/changes-to-hamachi-on-november-19th/
LogMeIn Hamachi is basically a NAT-traversing layer 2 VPN solution. They
avoided conflicts with RFC 1918 space by hijacking IPv4 space in 5/8, now
actively being allocated by
On Tue, 6 Nov 2012, Fred Baker (fred) wrote:
This note is rather lighter in weight and tone than its predecessor, and seems
like a good direction.
Can you explain your reasoning why this seems like a good direction.
For example, how would the new Note Well improve our situation in
the
On Tue, 6 Nov 2012, Stephan Wenger wrote:
So, to summarize, out of the 60 or so non-third-party disclosures that
have been made over the last 4+ months, only a few may or may not be
late; the rest almost certainly is not.
Do we have a list of known IPR for which no disclosure was filed
On Sun, 3 Jun 2012, Dave Crocker wrote:
Subject: maybe it's getting real
Sitting in a pub in the Tiergarten metro station, in Berlin, today, I checked
whether there were any open-access wireless points around.
There weren't.
It's very unfortunate not sharing bandwidth is getting real.
On Tue, 8 May 2012, Bob Hinden wrote:
https://www.facebook.com/jon.postel
I just tried going to this page and it says it doesn't exist. Has the problem
been fixed?
Looks like it. An hour ago i could still report the page, which I did
(and prob many more?)
Paul
On Mon, 7 May 2012, Stephen Farrell wrote:
The draft is for TLS, but it occurs to me to ponder.. would
similar approach work for IPsec IKEv2 as an alternative to
verify endpoints?
IPsec is in the WG charter, [1] but there's been zero energy
for that so far. I believe the chairs plan to poll
On Wed, 25 Apr 2012, Phillip Hallam-Baker wrote:
The browser providers do not hard fail on OCSP because doing so would
require them to wait for the OCSP response within the TLS handshake
and this is considered an unacceptable performance degradation.
And with the current ocsp.entrust.net
On Tue, 29 Nov 2011, Andrew Sullivan wrote:
On Tue, Nov 29, 2011 at 03:53:14PM +, Dave Cridland wrote:
Welcome to Toronto - ranked 7th most popular place in North America
amongst a non-representative self-selecting group of technical
people.
Obviously, not enough Canadians from outside
Anyone have more info on this?
Paul
-- Forwarded message --
Date: Thu, 17 Nov 2011 10:34:54
From: Vesna Manojlovic be...@xs4all.nl
To: p2p-...@lists.puscii.nl
Subject: Lawsuit against IETF/SIDR/RPKI?
X-Spam-Flag: NO
You've heard it here first ;-)
But it's still only a
On Fri, 14 Jan 2011, Phillip Hallam-Baker wrote:
I suggest that the IAB consider a policy for registries that requires all
cryptographic and application layer code
points to make use of an approved extensible identifier format, with the two
approved forms being URIs and ASN.1 OIDs.
-1
Not
On Fri, 16 Jul 2010, Tony Finch wrote:
unbound requires trust anchors in DS format which is somewhat more
convenient, though you still have to edit IANA's XML to convert it into
master file format.
You can also use DNSKEY statements in unbound:
~ grep trusted-keys /etc/unbound/unbound.conf
On Wed, 12 May 2010, Joe Abley wrote:
I'm actually slightly surprised that anybody is considering enhancements to FTP
in 2010.
I would have thought that given standardised alternatives which are kinder to
firewalls and more secure the logical next step would be to publish guidance
that
On Tue, 30 Mar 2010, Iljitsch van Beijnum wrote:
The chipkaart costs 7,50 euros but the train trip between Schiphol and
Maastricht is 5,85 euros cheaper with the chipkaart than with a paper ticket so
you still come out ahead. You can get one from the ticket machines I believe
but it probably
On Mon, 1 Mar 2010, Tony Finch wrote:
DNSSEC is already deployed in 12 top-level domains
Add a half for .uk :-) It has a deliberately invalid DNSKEY this week,
full deployment next week.
There is more then the 12 in itar. From the top of my head: .br .us .museum and
.pt,
and of course a
On Thu, 25 Feb 2010, Tony Finch wrote:
On Thu, 25 Feb 2010, Martin Rex wrote:
What does DNSCurve additionally provide
compared to a combination of traditional DNS with IPsec?
DNS-based keying.
RFC 4025 - A Method for Storing IPsec Keying Material in DNS
Paul
On Thu, 25 Feb 2010, Nikos Mavrogiannopoulos wrote:
Ssh without secure public key distribution mechanism is not really
secure cryptographically.
In general, public key cryptography is scure only if public key
distribution is secure.
Well as far as I know ssh works pretty well today and this
On Wed, 24 Feb 2010, Phillip Hallam-Baker wrote:
I would like to see us create an assumption that a given machine will
only use recursive resolution services from a specific trusted source.
Trust no one. More and more devices will do their own DNSSE validation,
and just use caches to get the
On Thu, 25 Feb 2010, Phillip Hallam-Baker wrote:
What does DNSCurve additionally provide
compared to a combination of traditional DNS with IPsec?
They appear to have an interest in actually listening to real world
requirements.
Of course a combination of DNS and IPSec would be a better
On Thu, 25 Feb 2010, Phillip Hallam-Baker wrote:
But SSH would be much better if we could integrate the key
distribution into a secured DNS.
See previous post. Already done and running.
And self-signed SSL certs would be
better if we could use hash values distributed through a secured DNS
On Wed, 24 Feb 2010, ty...@mit.edu wrote:
Of course, the Certicom folks didn't listen to me back then, and I
doubt any of them would listen to me now
Didn't RIM buy Certicom (trumping Verisign) ?
I'm not sure who owns the patents and who owns licenses and whether
the new owners would
On Wed, 24 Feb 2010, Tony Finch wrote:
On Wed, 24 Feb 2010, Shane Kerr wrote:
DNSSEC declares out of scope:
* the channel where DS records get added to the parent
Is that actually out of scope or just not specified yet?
Out of scope. It is the bootstrap problem. Though with RFC-5011
On Wed, 17 Feb 2010, Phillip Hallam-Baker wrote:
One of the big fallacies of DNSSEC is the idea that providing clients
access to the unfiltered authoritative DNS source is the same as
securing the DNS. That was the case when DNSSEC was designed, today
most endpoints would prefer to opt to
On Thu, 18 Feb 2010, Phillip Hallam-Baker wrote:
The point is not to protect the DNS. The point is to protect the
people. And that means that maybe you don't want your machine to
resolve every domain name.
That sounds very much like the tapping/crypto debate. You may not
secure your
On Thu, 18 Feb 2010, Phillip Hallam-Baker wrote:
The key point is choice. Just as some people CHOOSE to install
products such as Norton Anti-Virus that stop certain applications
running on their machine, the typical Internet user should probably
CHOOSE to use a DNS service that has the known
On Fri, 18 Sep 2009, John C Klensin wrote:
I am concerned that, if there is some incident --completely
unrelated to IETF-- that someone associated with the host or
hotel might overreact and decide to interpret, e.g., a
discussion about mandatory-to-implement cryptography, as pushing
too close
On Fri, 31 Jul 2009, Brian E Carpenter wrote:
I think that we *care* about IPR disclosures and that we *hate* the idea
of people observing IETF activity and concealing relevant patents. So having
a record of WG attendance is important; having a record of mailing list
membership would be the
On Wed, 3 Jun 2009, Christian Huitema wrote:
Also, it is actually possible to improve on DNSSEC by introducing additional knowledge.
If two domains have an establish relation, their servers can memorize the relevant public
keys. If a host has a relation with a domain, it can memorize that
On Tue, 2 Jun 2009, Masataka Ohta wrote:
For my domain: necom830.hpcl.titech.ac.jp, hierarechy of zones
have hops of ., jp, ac.jp, titech.ac.jp and
hpcl.titech.ac.jp. The authority hops are IANA, JPNIC, my
university, and my lab. Though you may have direct relationship
with IANA, JPNIC is the
On Wed, 3 Jun 2009, Masataka Ohta wrote:
You can, for example, bribe a personnel or two, against which there
is no cryptographical protection, which means PKI is weakly secure.
You have never heard of a Hardware Security Module?
Paul
___
Ietf
On Wed, 3 Jun 2009, Mark Andrews wrote:
You can, for example, bribe a personnel or two, against which there
is no cryptographical protection, which means PKI is weakly secure.
You have never heard of a Hardware Security Module?
HSM doesn't stop the wrong data being signed. It just
On Fri, 29 May 2009, Alessandro Vesely wrote:
transport security is pretty meaningless in the DNS world which operates
using a distributed caching system.
One has to trust each cache!
Your solution to protect the DNS is just trust everyone?
Given that it is pretty easy to predict a subset
On Fri, 29 May 2009, Alessandro Vesely wrote:
It's what the patch has reinforced. SCTP is more secure than the patched
bind, yet easier than DNSSEC.
where easier means update all the root and TLD servers and load balancers
and what not to support DNS over SCTP. While DNSSEC is supported
On Fri, 29 May 2009, Masataka Ohta wrote:
Though there seems to be some confusion that DNSSEC security were
end to end
It is.
, below is an excerpt from an authentic document by David
Clark on how PKI, including DNSSEC, involves certificate authorities
DNSSEC involves no certificates and
On Wed, 15 Apr 2009, Randy Presuhn wrote:
Do we have an RFC for how to format phone numbers?
ITU E.123 would be what you want.
http://www.itu.int/rec/T-REC-E.123-200102-I/e
Clause 2.8 hints at those annoying parenthesized things,
and 7.2 makes it clear it's not an appropriate notation
for
On Fri, 28 Nov 2008, Andrew Sullivan wrote:
That said, I don't want to make light of the end-point problem, since
TSIG between a stub and a recursor isn't a trivial problem today
either. Moreover, since end nodes in many environments get their
recursor's address(es) via DHCP, and since that
On Sat, 29 Nov 2008, Mark Andrews wrote:
It's worse. Before you can start validating on your own, or use some
trusted remote TSIG accessable resolver, you are likely to need
to accept some spoofs to get past the hotspot authentication.
Which is something the IETF should be
On Thu, 27 Nov 2008, Michael Richardson wrote:
You are. It's all ready.
DNSSEC can be done in the plenary by changing the recursive servers.
It's pretty close to being completely apt-get/yum/pkg_add able as being
on. What's missing is someone to decide what are the set of TAs to
On Thu, 27 Nov 2008, David Conrad wrote:
However, with that said, I personally believe the IETF network should turn on
DNSSEC validation in their caching servers and the IETF secretariat should
sign the IETF-related zones. I can't think of any reason why this should not
occur at this point.
On Fri, 28 Sep 2007, Jaap Akkerhuis wrote:
There are two major reasons for an organization to not want roaming
users to trust locally-assigned DNS servers.
Open recursive servers doesn't help in against man in the middle
attacks. If you want to avoid that use VPN's or (for DNS) TSIG.
On Fri, 28 Sep 2007, Dean Anderson wrote:
Maybe its not mentioned because its not a practical solution. But
whatever the reason it isn't mentioned, a 25 million user VPN is not
going to happen with 10/8. A comcast person recently complained on PPML
that there wasn't enough RFC1918 space for
On Fri, 28 Sep 2007, Joe Abley wrote:
I'm surprised by that comment.
I think it's a common use case that organisations who deploy VPNs have split
DNS; that is, namespaces available through internal network resolvers that do
not appear in the global namespace. In my experience, it is normal
58 matches
Mail list logo
