is going to be the ultimate source of trust among them. So you can be
absolutely certain they are never going to agree to it being ICANN.
On Fri, Mar 30, 2018 at 12:06 PM, Tony Finch wrote:
> Phillip Hallam-Baker wrote:
>
> > But even if we accept the need for updates, where does th
le.com would be better. Right now, I just do not know.
But what I do know is that nobody else should be allowed to register mmm:
URIs.
On 1 Mar 2016, at 09:55, Phillip Hallam-Baker wrote:
>
> > The _service._protocol approach in SRV is rather obviously a mistake.
> Given the function
It is a hard problem and it is possible that there is actually no solution.
All these systems consist of a chain or a graph of signed assertions. There
is no intrinsic ground truth in PKI. All that you can do is to define a
particular key or set of keys as producing the ground truth for your
parti
On Thu, Mar 29, 2018 at 3:18 PM, Suzanne Woolf
wrote:
>
> Should we refuse to document such things because they’re not in well-known
> open source codebases, or have otherwise not passed tests of goodness?
>
> It’s not a rhetorical question. Given that people are extending the
> protocol outside
On Wed, Mar 28, 2018 at 2:45 PM, Paul Vixie wrote:
>
> i'm in general agreement with each of the assertions made at each layer of
> quoting above, but i have two quibbles.
>
> first, they aren't reference implementations. not even BIND, which for
> many years i called a reference implementation,
Strong Internet Names is a concept that I have been developing for about 4
years now. It is an extension of concepts that Brian LaMachia and team
applied to the design of dotNET security with great success and I think it
has value applied at the network level.
The current draft can be found in HTM
--
From: Phillip Hallam-Baker
To: Jim Reid
Cc: dnsop WG
Bcc:
Date: Thu, 29 Mar 2018 11:41:30 -0400
Subject: Re: [DNSOP] New WG for document/protocol cleanup?
On Wed, Mar 28, 2018 at 1:12 PM,
Jim Reid wrote:
>
>
> > On 28 Mar 2018, at 18:02, Phillip Hallam-Baker
> wrot
A bit of context here, this is probably a document you have seen before and
it is one of those cleanup documents that tends to languish.
The reason I asked Dave to restart work on this draft is that I was
reviewing another draft (SMTPRPT) that clearly needs to register a new
prefix and indeed real
On Wed, Mar 28, 2018 at 1:12 PM,
Jim Reid wrote:
>
>
> > On 28 Mar 2018, at 18:02, Phillip Hallam-Baker
> wrote:
> > ... long rant snipped ...
> > Well that is how I plan to go forward at any rate.
>
> Good for you. Please come back to the IETF once you
A while back, I realized that I needed a full DNS client implementation to
do proper DNS discovery. So I reduced the existing specs to a file that
does capture the syntax:
https://github.com/hallambaker/Mathematical-Mesh/blob/master/Libraries/Goedel.Discovery/Domainer.domainer
I use that file to
It is potentially very useful that we have the underscore convention. We
could define wildcards that worked correctly (i.e. as expected) if we
wanted to.
The DNS was designed to publish addresses for hosts, we now use services.
As a result we have an overloading issue because we only have one hier
On Tue, Nov 21, 2017 at 3:54 PM, Viktor Dukhovni wrote:
> On Mon, Nov 20, 2017 at 01:10:43PM +, Tony Finch wrote:
>
>> Viktor's message has lots of sound advice, though I have one correction:
>>
>> > This language really should have been much more clear. In particular,
>> > the last item warr
On Thu, Jul 6, 2017 at 11:15 AM, John C Klensin wrote:
>
>
> --On Thursday, July 6, 2017 00:36 -0400 Phillip Hallam-Baker
> wrote:
>
> > There are changes to the DNS that are practical and those that
> > are not. For better or worse, I can't see any way that
>
There are changes to the DNS that are practical and those that are not. For
better or worse, I can't see any way that teaching DNS to use new classes
makes any sense at this point. The only point at which it would have made
sense was when internationalization happened. But the path chosen makes
mor
Shhh. don't confuse with facts.
On Fri, Mar 10, 2017 at 1:30 PM, Frederico A C Neves
wrote:
> On Fri, Mar 10, 2017 at 01:15:42PM -0500, Shumon Huque wrote:
> ...
> >
> > Apparently there are many folks in the community who think so, otherwise
> > NSEC3 would not have been developed. I personally
On Thu, Mar 9, 2017 at 4:05 PM, Roy Arends wrote:
>
> > On 9 Mar 2017, at 20:58, Phillip Hallam-Baker
> wrote:
> >
> > I suggest we first deploy NSEC0 which simply nulls out the whole
> NSEC/NXT issue entirely.
>
> What is NSEC0?
>
>
That which &qu
On Thu, Mar 9, 2017 at 4:05 PM, Roy Arends wrote:
>
> > On 9 Mar 2017, at 20:58, Phillip Hallam-Baker
> wrote:
> >
> > I suggest we first deploy NSEC0 which simply nulls out the whole
> NSEC/NXT issue entirely.
>
> What is NSEC0?
>
>
That which &qu
The perfect is the enemy of the good.
I suggest we first deploy NSEC0 which simply nulls out the whole NSEC/NXT
issue entirely. At this point anyone who is deploying DNSSEC is helping the
cause. Do not set membership requirements that exclude them.
Node insertion is a security concern for some DN
There are two reasons for splitting out the VRF
1) It is a useful building block
2) The intersection between the people who really understand the VRF math
and really understand DNS is very small
I think most DNSOps folk will want to treat VRF as a black box and let the
crypto folk put what they
On Mon, Feb 20, 2017 at 8:42 PM, Mark Andrews wrote:
>
>
> Zero if it is done right. We can easily extend the DNS to say
> "Fetch the additional record for the SRV records before answering"
> if you have this EDNS option present or just have the server do it
> without the option. There is nothi
On Mon, Feb 20, 2017 at 4:08 PM, Ben Schwartz wrote:
> On Mon, Feb 20, 2017 at 3:39 PM, Phillip Hallam-Baker <
> ph...@hallambaker.com> wrote:
>
>> I really don't like the proposal at all. The idea of beginning the TLS
>> handshake in DNS is sound. But it i
I really don't like the proposal at all. The idea of beginning the TLS
handshake in DNS is sound. But it is a completely new handshake and
authentication layer.
Right now we have a bit of a mess with service discovery. We have a solid
proposal that makes sense written up as a standard and we have
cause IANA does 'assignments' that are not
'registrations' doesn't mean that is right or should continue.
On Thu, Oct 6, 2016 at 9:56 PM, Paul Hoffman wrote:
> On 6 Oct 2016, at 18:09, Phillip Hallam-Baker wrote:
>
> On Thu, Oct 6, 2016 at 5:13 PM, Jaap Akkerhuis
On Thu, Oct 6, 2016 at 5:13 PM, Jaap Akkerhuis wrote:
> Robert Edmonds writes:
>
> > Donald Eastlake wrote:
> > > Sure, you can consider the root zone to be the registry for TLDs but
> the
> > > point is the xn-- labels are recommended to be interpreted specially
> at the
> > > user interfac
On Thu, Oct 6, 2016 at 1:24 PM, wrote:
>
> >I have been looking for the IANA registry in which the IDNA prefix xn--
> is allocated and have not been able to find it. I can see the following
> possibilities
>
> >1) There isn't such a registry. The allocation is purely ad hoc
>
> >2) There is
I have been looking for the IANA registry in which the IDNA prefix xn-- is
allocated and have not been able to find it. I can see the following
possibilities
1) There isn't such a registry. The allocation is purely ad hoc
2) There is a registry but none of the IDNA RFCs bother to list it as a
nor
There is actually a fifth type of name, escaped names. Right now, the only
names we have of this type are SRV protocol tags, (_http._tcp.example.com)
and internationalized names (xn—wev.com)
I want to add a third set of escaped names, one that has similar
functionality to .onion but does not leak
In response to the discussion of where the use of TXT records is discussed, see:
https://tools.ietf.org/html/rfc6764
This in turn cites:
https://tools.ietf.org/html/rfc6763#section-6
Which seems like the way to do these things.
___
DNSOP mailing list
On Tue, Mar 1, 2016 at 1:13 PM, John Levine wrote:
>>So while SRV and NAPTR and the TXT records are stuck using the two
>>level approach, there is also a clear need for a meta-discovery record
>>that only uses the service prefix.
>
> Maybe.
>
>>Using SRV discovery you might use:
>>
>>_mmm._tcp.exa
On Tue, Mar 1, 2016 at 11:59 AM, Ray Bellis wrote:
>
>
> On 01/03/2016 16:56, John Levine wrote:
>
>> If you take a look at that registry, it's a stroll down memory lane.
>> You'll find NVP-II from RFC 741 in 1977, PUP and XNS-IDP from Xerox in
>> 1980, and other great hits from networking history
On Mon, Feb 29, 2016 at 5:32 PM, Ray Bellis wrote:
>
>
> On 29/02/2016 22:27, John R Levine wrote:
>
>> The existing port and service registry already has all of the _service
>> names, and is updated as people invent new services. What's the benefit
>> of duplicating it rather than just pointing
If you want to do this...
Why not just do Web Sockets and run plain old DNS over TCP. Its not
going to be tremendously fast but it is the shortest distance between
two points and there would be almost no new code needed.
___
DNSOP mailing list
DNSOP@iet
Objections so far
* The approach is dated (not fast prime rigid) and the randomness isn't
established to be rigid.
* DNSSEC requires a single algorithm for interop
* The code points are 8 bit and thus scarce
* We should do Curdle first.
I am opposed to Brainpool for all the above and in addition,
On Thu, Mar 12, 2015 at 10:42 AM, Paul Hoffman
wrote:
> On Mar 12, 2015, at 6:53 AM, Phillip Hallam-Baker
> wrote:
> > Its a bug in the spec.
>
> The terminology document is the wrong place to deal with bugs in the spec.
> We are happy to list differences of opinion about
Its a bug in the spec.
Glue records should never have existed and they have caused nothing but
implementation confusion.
I understand the reasons why people imagine they are justified. But a
mistake is still a mistake.
At this point we cannot get rid of them.
___
Can we change the name, please?
Spartacus Club was the name of the pedophile rapist organization at
the center of the on ongoing UK criminal enquiry involving 8 MPs and
three police forces. There is also an international dimension.
There is a significant probability it is going to become a PR
lia
If you want to do anything useful in counter-censorship then you have to think
of using steganography
So don't call it DNS and don't put the parts of the plan designed for counter
censorship prominently in the draft
Port 443 is loaded with censorship issues. If you want to get your packets pa
I understand what is being attempted here and I am a big fan of JSON. But I
don't see the value in representing DNS information in an alternative
syntax.
If we are going to change the discovery interface I would want to go a step
up in abstraction and present the type of interface the application
On Sat, Oct 25, 2014 at 2:08 PM, Paul Vixie wrote:
>
>
> Stephane Bortzmeyer
> Saturday, October 25, 2014 9:05 AM
>
> On Tue, Oct 21, 2014 at 02:14:49PM +0900,
> Masataka Ohta
> wrote
> a message of 27 lines which said:
>
>
>
> Right, NXDOMAIN returned by some broken implementation to
>
On Sun, Oct 26, 2014 at 9:52 AM, Livingood, Jason <
jason_living...@cable.comcast.com> wrote:
>
> Warren - Your suspicions are right on the money. A good reference is
> http://dns.comcast.net/images/files/dnssec_validation_failure_nasagov_20120118_final.pdf.
> Take a look at the flak we got on pag
Paul,
It is a VeriSign patent, its just being shown on the Google patent serach
engine
On Sat, Oct 25, 2014 at 1:53 PM, Paul Vixie wrote:
>
>
> Stephane Bortzmeyer
> Saturday, October 25, 2014 2:24 AM
> [Copy to dnsop since the qname minimisation draft is now a WG item at
> dnsop.]
>
> On T
The claims are broad, not specific to one field of use.
But there isn't a patent yet and they may have been waiting to file after
grant.
It is possible for someone other than the IPR holder to file but best if
its the IPR holder.
The mere existence of a patent does not necessarily mean an intent
If we are going there, I would want to know how common the configurations are.
There is zero additional overhead for www.example.com
Outside this list how common are hierarchies more than 4 levels deep in
practice?
This isn't a functionality issue, it's purely performance. So I suggest a 5%
mi
as is suggested it will soon collapse of its
own accord. I rather suspect however that the fears are unfounded.
On Mon, Oct 20, 2014 at 2:32 PM, Phillip Hallam-Baker wrote:
>
>
> On Tue, Oct 7, 2014 at 12:04 AM, Tim Wicinski wrote:
>
>> Dear DNSOP WG,
>>
>> After
On Tue, Oct 7, 2014 at 12:04 AM, Tim Wicinski wrote:
> Dear DNSOP WG,
>
> After discussions about the landing spot of this document, DNSOP vs the
> newer DNS Privacy WG, it was realized the updated DNSOP charter
> specifically had work like this in mind.
>
> This starts a Call for Adoption for dr
On Mon, Jul 7, 2014 at 12:42 PM, Paul Vixie wrote:
>
> there are two kinds of channel in dns queries. (i'm not going to account
> for updates or zone transfers here.)
>
> one channel is from the stub to the recursive. it's pointless to add
> secrecy to that unless a stub wants to use a very dista
This is really a design question.
As far as I am concerned, DNS is and always will be a first class Internet
protocol. It is the foundation for everything else. The syntax etc can
change but it is a building block other stuff should build on, not
something that can leverage other facilities.
So t
On Fri, Jun 6, 2014 at 8:38 PM, Dan Wing wrote:
>
> On Jun 3, 2014, at 10:26 AM, Phillip Hallam-Baker
> wrote:
>> One of the biggest mistakes in TLS and DTLS is that they are built
>> around the assumption that there is a public key handshake at the
>> start of ea
On Tue, May 20, 2014 at 12:06 AM, joel jaeggli wrote:
> On 5/19/14, 1:09 PM, John Heidemann wrote:
>>
>> Folks,
>>
>> I believe consensus was that dnsop needs a problem statement about DNS
>> privacy before we explore possible solutions.
>
> If I were to speculate on the basis of the dicussion her
On Fri, Apr 25, 2014 at 10:46 AM, Ralf Weber wrote:
> Moin!
>
> On 25 Apr 2014, at 16:22, Tirumaleswar Reddy (tireddy)
> wrote:
>> Any specific reason for the firewalls to permit TCP/53 other than for zone
>> transfer ?
> Wat? Because it is defined in the RFC. RFC1035 may not been totally clear
On Thu, Apr 24, 2014 at 11:19 AM, Joe Abley wrote:
>
> On 24 Apr 2014, at 10:53, Phillip Hallam-Baker wrote:
>
>> If you want to use TLS with DNS then use port 443. One of the effects
>> of firewalls is that we now only have three ports for all protocols:
>>
>
On Thu, Apr 24, 2014 at 9:52 AM, Ralf Weber wrote:
> Moin!
>
>
> On 24.04.2014, at 15:28, "Tirumaleswar Reddy (tireddy)"
> wrote:
>
>>> -Original Message-
>>> From: dns-privacy [mailto:dns-privacy-boun...@ietf.org] On Behalf Of
>>> Nicholas
>>> Weaver
>>> Sent: Thursday, April 24, 2014
On Wed, Apr 23, 2014 at 7:11 PM, Joe Abley wrote:
>
> On 23 Apr 2014, at 18:32, Phillip Hallam-Baker wrote:
>
>> We can't run over port 53 (trust me, I tried).
>
> You have doubts about the approach described in
> draft-hzhwm-start-tls-for-dns-00? Those would b
I agree that DTLS does not solve any problems for DNS. The basic
problem is that DTLS is still based around the notion of a session
where the server stores per connection state. So you might as well use
TLS for this application.
But TLS is not the only option available. Or rather using TLS to
secu
On Wed, Apr 2, 2014 at 11:24 PM, Phillip Hallam-Baker wrote:
>
>
>
> On Wed, Apr 2, 2014 at 10:48 PM, Andrew Sullivan
> wrote:
>
>> On Wed, Apr 02, 2014 at 09:07:07PM -0400, Phillip Hallam-Baker wrote:
>> > 1) Client -> Resolver
>>
>> > Changing
On Wed, Apr 2, 2014 at 10:48 PM, Andrew Sullivan wrote:
> On Wed, Apr 02, 2014 at 09:07:07PM -0400, Phillip Hallam-Baker wrote:
> > 1) Client -> Resolver
>
> > Changing 1 is the easiest and also the part that is most in need.
>
> >From where I sit, that projec
On Wed, Apr 2, 2014 at 7:31 PM, Andrew Sullivan wrote:
> On Wed, Apr 02, 2014 at 07:21:11PM -0400, Phillip Hallam-Baker wrote:
>
> > Which is why I have been pushing the notion that if we are going to do
> DNSE
> > then part of the DNSE solution should be to get us out of th
On Wed, Apr 2, 2014 at 11:19 AM, 🔒 Roy Arends wrote:
> On 02 Apr 2014, at 15:19, Jim Reid wrote:
>
> > There's been a lot of noise and very little signal in the recent
> discussion.
> >
> > It would be helpful if there was real data on this topic. Is an RSA key
> of N bits too "weak" or too "str
On Tue, Apr 1, 2014 at 10:48 PM, Paul Hoffman wrote:
> On Apr 1, 2014, at 7:37 PM, Olafur Gudmundsson wrote:
>
> > Why not go to a good ECC instead ? (not sure which one, but not P256 or
> P384)
>
> Why not P256 or P384? They are the most-studied curves. Some of the newer
> curves do have advant
On Tue, Apr 1, 2014 at 9:05 AM, Nicholas Weaver
wrote:
>
> On Apr 1, 2014, at 5:39 AM, Olafur Gudmundsson wrote:
> >
> > Doing these big jumps is the wrong thing to do, increasing the key size
> increases three things:
> > time to generate signatures
> > bits on the wire
> > ver
On Fri, Mar 28, 2014 at 2:29 PM, Joe Abley wrote:
>
> On 28 Mar 2014, at 10:26, Phillip Hallam-Baker wrote:
>
> > VeriSign is acting on ICANN's instructions.
>
> I think actually that Verisign is acting on NTIA's instructions under the
> cooperative agreem
On Fri, Mar 28, 2014 at 11:28 AM, Thierry Moreau <
thierry.mor...@connotech.com> wrote:
> On 03/27/14 13:56, Nicholas Weaver wrote:
>
>>
>>
>> So why the hell do the real operators of DNSSEC that matters, notably com
>> and ., use 1024b RSA keys?
>>
>> And don't give me that key-roll BS: Give me a
On Fri, Mar 28, 2014 at 9:50 AM, Joe Abley wrote:
>
> On 28 Mar 2014, at 9:06, Phillip Hallam-Baker wrote:
>
> > Therefore ICANN needs to sign the root zone with 2048 before we consider
> it signed. End of story.
>
> Small point of clarity: the only key that ICANN m
On Fri, Mar 28, 2014 at 9:01 AM, Tony Finch wrote:
> Paul Wouters wrote:
>
> > On Thu, 27 Mar 2014, Nicholas Weaver wrote:
> >
> > > For an attacker, the root ZSK is not 1 month validity, since an
> attacker
> > > who's in a position to take advantage of such a ZSK compromise is
> going to
> > >
Nope.
ALL 1024 bit certs of every description are covered including end-entity.
On Thu, Mar 27, 2014 at 3:35 PM, Paul Wouters wrote:
> On Thu, 27 Mar 2014, Nicholas Weaver wrote:
>
> Because the browsers have already decided killing of 1024b CAs is a good
>> idea, and they could revoke just t
On Thu, Mar 27, 2014 at 11:05 AM, Nicholas Weaver wrote:
>
> Frankly speaking, since the root uses NSEC rather than NSEC3, IMO it
> should be 4096b for both the KSK and ZSK. But I'd be happy with 2048b.
> Using 1024b is a recipe to ensure that DNSSEC is not taken seriously.
>
>
I think I know h
On Thu, Mar 27, 2014 at 10:52 AM, Paul Hoffman wrote:
> On Mar 27, 2014, at 6:56 AM, Nicholas Weaver
> wrote:
>
> > and 1024B is estimated at only "a thousand times harder".
>
> Does that estimate include a prediction that the method to factor RSA will
> improve significantly as it has in the pas
The NIST Guidance is from 2009. It is long since obsolete.
This is one of the reasons why we need to take advice on crypto algorithms
in house and make them IETF wide. Which is why I was asked to write this:
https://datatracker.ietf.org/doc/draft-hallambaker-consensuscrypto/
Having DNSSEC use 1
On Fri, Mar 21, 2014 at 10:59 AM, Paul Vixie wrote:
>
>
> Phillip Hallam-Baker wrote:
>> This was the use case that originally drove the development of OmniBroker.
>>
>> If we do DNS Encryption right it is going to be very easy for end
>> users to chose their D
This was the use case that originally drove the development of OmniBroker.
If we do DNS Encryption right it is going to be very easy for end
users to chose their DNS provider and very hard for the authorities to
block them.
Security is a balance. Going through 8.8.8.8 rather than direct means
tha
On Tue, Mar 11, 2014 at 11:26 AM, Stephane Bortzmeyer wrote:
> On Sun, Mar 09, 2014 at 11:28:18AM +0100,
> Florian Weimer wrote
> a message of 20 lines which said:
>
> > In most jurisdictions, home networks use recursive resolvers whose
> > operators are required by law to provide cleartext cop
On Mon, Mar 10, 2014 at 1:44 PM, Tony Finch wrote:
> Phillip Hallam-Baker wrote:
> >
> > First off it means that if the recursive is being used in discovery-only
> > mode it can simply pass data from the authoritative to the stub without
> > checking the DNSSEC
On Mon, Mar 10, 2014 at 1:11 PM, Tony Finch wrote:
> Stephane Bortzmeyer wrote:
> >
> > The only place where server authentication could be useful is between
> > a stub and the first resolver.
>
> I don't think it is as simple as that.
>
> There are good reasons for using a recursive resolver th
On Sun, Mar 9, 2014 at 10:26 AM, Florian Weimer wrote:
> * Phillip Hallam-Baker:
>
> > But first, cite actual legal authority because I don't believe your
> > interpretation of the law is remotely correct.
>
> § 8 Abs. 3 TKÜV:
>
> | Wenn der Verpflichtete d
On Sun, Mar 9, 2014 at 6:28 AM, Florian Weimer wrote:
> * Phillip Hallam-Baker:
>
> > For a heavily trafficked resolver, the resolver-authoritative
> > interaction can be addressed with caching and by pre-fetching the
> > bulk of the requests. But this approach does not
In my view we need to consider different privacy issues in the
stub-resolver and resolver-authoritative interactions.
In the stub-resolver interaction the primary objective is to encrypt
requests and responses without impacting latency.
For a heavily trafficked resolver, the resolver-authoritativ
I think we need some use cases to ground discussion. These are the use
cases I have been considering:
A) Alice, surfing the Web from her own machine at home does not want her
Web browsing history to be revealed to other parties.
A1) Note here that Alice might also use the same machine to access
On Thu, Sep 12, 2013 at 2:07 PM, Ted Lemon wrote:
> On Sep 12, 2013, at 1:49 PM, "Dickson, Brian"
> wrote:
> > In order to subvert or redirect a delegation, the TLD operator (or
> > registrar) would need to change the DNS server name/IP, and replace the
> DS
> > record(s).
>
> Someone who posses
On Thu, Sep 12, 2013 at 1:21 PM, Theodore Ts'o wrote:
> On Thu, Sep 12, 2013 at 04:46:01PM +, Ted Lemon wrote:
> >
> > The model for this sort of validation is really not on a per-client
> > basis, but rather depends on routine cross-validation by various
> > DNSSEC operators throughout the n
OK lets consider the trust requirements here.
1. We only need to know the current time to an accuracy of 1 hour.
2. The current time is a matter of convention rather than a natural
property. It is therefore impossible to determine the time without
reference to at least one trusted party.
2a) A t
On Wed, Sep 11, 2013 at 12:26 PM, Nicholas Weaver wrote:
>
> On Sep 11, 2013, at 9:18 AM, Phillip Hallam-Baker
> wrote:
> >
> > The DNS is the naming infrastructure of the Internet. While it is in
> theory possible to use the DNS to advertise very rapid changes to Intern
On Wed, Sep 11, 2013 at 12:08 PM, Paul Wouters wrote:
> 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 ar
rition, so that it should be possible
> for a ten-year-old validator to successfully and securely bootstrap. Think
> of a fifteen-year-old root hints file, which still after all that time
> contains eight valid root server IP addresses: enough to bootstrap.
>
> Phillip Hallam-Baker a
On Tue, Feb 1, 2011 at 2:30 AM, Paul Wouters wrote:
> On Tue, 1 Feb 2011, Brian Dickson wrote:
>
> This may be good enough for DNSSEC purposes.
>>
>
> At least to then do ntp and and see that it matches our rough expectation.
> Though in all, if the attacker is your controlling upstream, you are
On Mon, Jan 31, 2011 at 5:14 PM, Joe Abley wrote:
>
> > Either way, it's a local trust anchor... and I don't see why X.509
> > keys are any less compromisable than DNS keys...
>
> The difference is that X.509 keys, as deployed by CAs, have expected
> lifetimes measured in decades. Right now we do
David,
When I originally looked at this scheme I thought that it was intended to
reduce the attack surface in the manner you describe.
Clearly if you have two controls, A and B and BOTH must be compromised, the
system is less likely to be compromised than either A or B.
But the design approach t
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
lits 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
If the problem is the lack of checks and balances, the solution should be to
introduce checks and balances.
Moving from a market based solution with multiple CAs to a monopoly with one
trust provider does not help at all. It makes the situation much worse
because there is now no possibility of cho
motivating the
design.
On Sat, Oct 2, 2010 at 9:49 PM, Marsh Ray wrote:
> On 10/02/2010 03:16 PM, Ben Laurie wrote:
>
>> On 1 October 2010 16:15, Phillip Hallam-Baker wrote:
>>
>>>
>>> The problem with that approach is that the attacker now has two
>
On Fri, Oct 1, 2010 at 6:05 PM, Matt McCutchen wrote:
> On Fri, 2010-10-01 at 11:29 -0400, Phillip Hallam-Baker wrote:
> > In particular I am very concerned about the particular approach being
> > taken to security policy. What the proposers are attempting to do is
> > to cr
On Fri, Oct 1, 2010 at 12:02 PM, Ben Laurie wrote:
> On 1 October 2010 08:29, Phillip Hallam-Baker wrote:
> > The reason that I started with the requirement to use SSL is that
> security
> > policy relating to trust criteria is meaningless until you have a
> statement
&
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
If so, any chance of turning on the audio
(apols for not making it in person, but I only started work for my new
employer (Comodo Inc.) 4 hours ago).
On Mon, Jul 26, 2010 at 12:58 PM, Sean Turner wrote:
> Ondřej Surý wrote:
>>
>> On 26.7.2010 17:46, Paul Hoffman wrote:
>>>
>>> At 4:25 PM +0200
94 matches
Mail list logo
