At 20:32 05-09-2013, Vinayak Hegde wrote:
While it is nice to do a dedication of this meeting to the SA
surveillance, I do not see us solving any issue here. It is merely a
"feel-good" measure without real impact.
:-)
Second, technology can never fix what is essentially a political
problem.
Subject: Re: Bruce Schneier's Proposal to dedicate November meeting to saving
the Internet from the NSA Date: Fri, Sep 06, 2013 at 09:04:41AM +0300 Quoting
Jari Arkko (jari.ar...@piuha.net):
> I think we should seize this opportunity to take a hard look at what we can
> do better. Yes, it is com
Bruce might not know that we have already various activities ongoing. I
just recently produced a short writeup about the efforts related to this
topic ongoing at the last IETF meeting on my blog:
http://www.tschofenig.priv.at/wp/?p=993
Ciao
Hannes
On 06.09.2013 03:17, Dean Willis wrote:
This
Hi Adrian,
I am updating this draft, but one issue is about the new small section.
You said "adding a small section including all of the statements you made in
your email", but I really don't know which kind of section should be added to
cover various aspects including management tools, OAM, al
On 09/05/2013 08:19 PM, Brian E Carpenter wrote:
Tell me what the IETF could be doing that it isn't already doing.
I'm not talking about what implementors and operators and users should
be doing; still less about what legislators should or shouldn't be
doing. I care about all those things, but t
- Original Message -
From: "Phillip Hallam-Baker"
To: "Andrew Sullivan"
Cc: "IETF Discussion Mailing List"
Sent: Friday, September 06, 2013 4:56 AM
> On Thu, Sep 5, 2013 at 11:32 PM, Andrew Sullivan
wrote:
>
> > On Fri, Sep 06, 2013 at 03:28:28PM +1200, Brian E Carpenter wrote:
> > >
> >
On Fri, Sep 6, 2013 at 12:16 PM, SM wrote:
> In a Last Call comment a few months ago it was mentioned that a
> specification takes the stance that security is an optional feature. I
> once watched a Security Area Director spend thirty minutes trying to
> explain to a working group that security
On 06.09.2013 04:36, Brian E Carpenter wrote:
I'm not saying there's no issue or no work to do, but what's new about
any of this?
Still at the end of last year I remember conversations in working groups
that questions why we need TLS security for protocols like SCIM (a
protocol that shuffles
Surely, pgp signing in vain?
Don't know about you, but I value plausible deniability.
Lloyd Wood
http://sat-net.com/L.Wood/
From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Randy Bush
[ra...@psg.com]
Sent: 06 September 2013 01:45
To: IE
On 06/09/2013 04:19, Brian E Carpenter wrote:
On 06/09/2013 15:08, Ted Lemon wrote:
On Sep 5, 2013, at 9:36 PM, Brian E Carpenter
wrote:
I'm sorry, I don't detect the emergency.
I think we all knew NSA was collecting the data. Why didn't we do something
about it sooner? Wasn't it an eme
Summarising a *lot* :-)
On 09/06/2013 11:30 AM, Stewart Bryant wrote:
>
> There is a whole bunch of stuff we can do
I fully agree. Some more detail on one of those...
We setup the perpass list [1] as a venue for triaging
specific proposals in this space. A few weeks in, we
have one I-D [2] (ve
On 06.09.2013 13:30, Stewart Bryant wrote:
Tell me what the IETF could be doing that it isn't already doing.
It really depends where you see the boundaries of the IETF.
For some the IETF only produces documents and that's it. Clearly, we
have a lot of specification work ongoing in different ar
IMHO. There is no amount of engineering that can fix stupid people doing
stupid things... on both sides of the stupid line.
-J
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/6/13 1:47 AM, Adam Novak wrote:
> On 09/05/2013 08:19 PM, Brian E Carpenter wrote:
>> Tell me what the IETF could be doing that it isn't already
>> doing.
>>
>> I'm not talking about what implementors and operators and users
>> should be doing; s
On Fri, Sep 6, 2013 at 7:07 AM, Hannes Tschofenig wrote:
> On 06.09.2013 13:30, Stewart Bryant wrote:
>
>> Tell me what the IETF could be doing that it isn't already doing.
>>
> It really depends where you see the boundaries of the IETF.
>
> For some the IETF only produces documents and that's it
On 06/09/13 14:07, Hannes Tschofenig wrote:
While we are able to fill gaps in security protocols fairly quickly we
don't always seem to make the right choices because the interests of
various participants are not necessarily aligned.
So, what if an NSA guys comes in and proposes backdoor to be
On 9/6/13 3:04 PM, Martin Sustrik wrote:
> So, what if an NSA guys comes in and proposes backdoor to be added to
> a protocol? Is it even a valid interest? Does IETF as an organisation
> have anything to say about that or does it remain strictly neutral?
>
It's happened before and we as a communit
Dave:
>> is pgp compromised?
>
> PGP is a packaging method. Absent grossly incompetent packaging -- and I've
> never heard claims that PGP or S/MIME were guilty of that -- my sense is that
> the interesting security mechanisms are the underlying algorithms.
>
> Is there something about PGP th
On 9/6/13 12:54 AM, t.p. wrote:
- Original Message -
From: "Phillip Hallam-Baker"
Cc: "IETF Discussion Mailing List"
Sent: Friday, September 06, 2013 4:56 AM
The design I think is practical is to eliminate all UI issues by
insisting that encryption and decryption are transparent. Any
Abdussalam,
Thanks again, following IETF last call I'll discuss actions to take on the
draft with the IESG.
Cheers,
Andy
On Thu, Sep 5, 2013 at 6:00 PM, Abdussalam Baryun <
abdussalambar...@gmail.com> wrote:
> Thanks Andrew, I am happy to see a survey draft, I never seen one
> before in IETF,
I wouldn't focus on government surveillance per se. The IETF should
consider that breaking privacy is much easier than it used to be,
particularly given consolidation of services at all layers, and take
that into account in our engineering best practices. Our mission is
to make the Internet bette
* Brian E Carpenter wrote:
>Tell me what the IETF could be doing that it isn't already doing.
The United States justify these programs saying they are primarily used
to support their various current and future war efforts. Not meeting at
any level in countries currently at war might be a sound IET
> From: Martin Millnert
> Bruce was ... suggesting that encrypting everything on the wire makes
> both metadata and payload collection from wires less valuable. Here
> comes the key point: Encrypting everything on the wire raises the cost
> for untargeted mass surveillance sig
--On Friday, September 06, 2013 06:20 -0700 Pete Resnick
wrote:
> Actually, I disagree that this fallacy is at play here. I
> think we need to separate the concept of end-to-end encryption
> from authentication when it comes to UI transparency. We
> design UIs now where we get in the user's fac
Theodore Ts'o wrote:
> Speaking of which, Jim Gettys was trying to tell me yesterday that
> BIND refuses to do DNSSEC lookups until the endpoint client has
> generated a certificate.
That is wrong. DNSSEC validation affects a whole view - i.e. it is
effectively global.
Clients can request DNSSE
On Fri, Sep 06, 2013 at 03:26:42PM +0100, Tony Finch wrote:
> Theodore Ts'o wrote:
>
> > Speaking of which, Jim Gettys was trying to tell me yesterday that
> > BIND refuses to do DNSSEC lookups until the endpoint client has
> > generated a certificate.
>
> That is wrong. DNSSEC validation affect
+1. I'd +10 if I could :-)
> One thing that would be helpful is to encourage the use of
> Diffie-Hellman everywhere. Even without certificates that can be
> trusted, we can eliminate the ability of casual, dragnet-style
> surveillance. Sure, an attacker can still do a MITM attack. But (a)
> peo
On 9/6/13 7:02 AM, John C Klensin wrote:
...It may still be
good protection against more casual attacks, but we do the users
the same disservice by telling them that their transmissions are
secure under those circumstances that we do by telling them that
their data are secure when they see a litt
One thing that would be helpful is to encourage the use of
Diffie-Hellman everywhere. Even without certificates that can be
trusted, we can eliminate the ability of casual, dragnet-style
surveillance. Sure, an attacker can still do a MITM attack. But (a)
people who are more clueful can do certif
On Fri, Sep 06, 2013 at 06:20:48AM -0700, Pete Resnick wrote:
>
> In email,
> we insist that you authenticate the recipient's certificate before
> we allow you to install it and to start encrypting, and prefer to
> send things in the clear until that is done. That's silly and is
> based on the ass
On 2013-09-06, at 10:16, Theodore Ts'o wrote:
> On Fri, Sep 06, 2013 at 06:20:48AM -0700, Pete Resnick wrote:
>>
>> In email,
>> we insist that you authenticate the recipient's certificate before
>> we allow you to install it and to start encrypting, and prefer to
>> send things in the clear un
> From: Scott Brim
> I wouldn't focus on government surveillance per se. The IETF should
> consider that breaking privacy is much easier than it used to be ...
> right now the Internet's weakness in privacy is far from "better". The
> mandatory security considerations section
On Sep 6, 2013, at 2:46 AM, SM wrote:
> At 20:08 05-09-2013, Ted Lemon wrote:
>> I think we all knew NSA was collecting the data. Why didn't we do
>> something about it sooner? Wasn't it an emergency when the PATRIOT act was
>> passed? We certainly thought it was an emergency back in the d
On Fri, Sep 06, 2013 at 08:20:17AM -0700,
Dave Crocker wrote
a message of 21 lines which said:
> We currently do not have a concise catalog the basic 'privacy'
> threats and their typical mitigations, appropriate for concern with
> IETF protocols.
What about RFC 6973?
On Fri, Sep 6, 2013 at 10:55 AM, Dave Crocker wrote:
> In other words, the IETF needs to assume that we don't know what will work
> for end users and we need to therefore focus more on processing by end
> /systems/ rather than end /users/.
... and do not close off any options because we assume pe
On 9/6/2013 5:51 AM, Jorge Amodio wrote:
IMHO. There is no amount of engineering that can fix stupid people doing
stupid things... on both sides of the stupid line.
Correct. Within the IETF, the most serious example of stupidity is any
line of analysis that considers end-users to be stupid
On Fri, Sep 6, 2013 at 11:41 AM, Pete Resnick wrote:
> OK, one last nostalgic anecdote about Eudora before I go back to finishing
> my spfbis Last Call writeup:
>
> MacTCP (the TCP/IP stack for the original MacOS) required a handler routine
> for ICMP messages for some dumb reason; you couldn't ju
Gert Doering wrote:
> Hi,
>
> On Wed, Sep 04, 2013 at 06:25:17PM +0900, Lorenzo Colitti wrote:
>>> Sure, but the majority are mandatory, and don't forget that some of them
>>> are quite large (e.g., "implement RFC 6204"). Also, I believe it's not the
>>> IETF's role to produce vendor requirements
> From: Spencer Dawkins
> I have to wonder whether weakening crypto systems to allow pervasive
> passive monitoring by "national agencies" would weaken them enough for
> technologically savvy corporations to monitor their competitors, for
> instance.
More importantly, if cryp
On Sep 6, 2013, at 3:25 AM, Måns Nilsson wrote:
> I do think that more distributed technoligies like DANE play an important
> rôle here.
Right, because there's no way the NSA could ever pwn the DNS root key.
What we should probably be thinking about here is:
- Mitigating single points of fail
--On Friday, September 06, 2013 08:41 -0700 Pete Resnick
wrote:
>...
> Absolutely. There is clearly a good motivation: A particular
> UI choice should not *constrain* a protocol, so it is
> essential that we make sure that the protocol is not
> *dependent* on the UI. But that doesn't mean that
There are a lot more threats to privacy than just the NSA
We currently do not have a concise catalog the basic 'privacy' threats
and their typical mitigations, appropriate for concern with IETF
protocols. In effect, every new protocol effort must start with a blank
sheet, and invent its ow
--On Friday, September 06, 2013 07:38 -0700 Pete Resnick
wrote:
> Actually, I think the latter is really what I'm suggesting.
> We've got do the encryption (for both the minimal protection
> from passive attacks as well as setting things up for doing
> good security later), but we've also got t
hi Scott, all,
On Sep 6, 2013, at 3:45 PM, Scott Brim wrote:
> I wouldn't focus on government surveillance per se. The IETF should
> consider that breaking privacy is much easier than it used to be,
> particularly given consolidation of services at all layers, and take
> that into account in ou
--On Friday, September 06, 2013 10:43 -0400 Joe Abley
wrote:
>> Can someone please tell me that BIND isn't being this stupid?
>
> This thread has mainly been about privacy and confidentiality.
> There is nothing in DNSSEC that offers either of those,
> directly (although it's an enabler throug
On 9/6/2013 8:34 AM, Stephane Bortzmeyer wrote:
On Fri, Sep 06, 2013 at 08:20:17AM -0700,
Dave Crocker wrote
a message of 21 lines which said:
We currently do not have a concise catalog the basic 'privacy'
threats and their typical mitigations, appropriate for concern with
IETF protocols.
Hi Vinayak,
At 01:13 06-09-2013, Vinayak Hegde wrote:
It is tragic if the community does understand strong encryption is
essential in many cases (with the caveat that it is not a panacea
for all security breaches) As for raising issues at the last-call.
Why not ? The last-call is no different t
On 9/6/13 8:23 AM, John C Klensin wrote:
I think that one of the more important things we
can do is to rethink UIs to give casual users more information
about what it going on and to enable them to take intelligent
action on decisions that should be under their control. There
are good reasons w
Brian E Carpenter wrote:
>> I think we all knew NSA was collecting the data. Why didn't we do
>> something about it sooner? Wasn't it an emergency when the PATRIOT
>> act was passed? We certainly thought it was an emergency back in the
>> days of Skipjack, but then they convinc
You're right that a flat mesh is not the best topology for
long-distance communication, especially with current routing
protocols, which require things like global lists of all routeable
prefixes.
On the protocol front, I suggest that the IETF develop routing
protocols that can work well in a flat
John C Klensin wrote:
>
> Please correct me if I'm wrong, but it seems to me that
> DANE-like approaches are significantly better than traditional
> PKI ones only to the extent to which:
>
> - The entities needing or generating the certificates
> are significantly more in control of th
On 9/6/13, Brian E Carpenter wrote:
>
> Tell me what the IETF could be doing that it isn't already doing.
>
> I'm not talking about what implementors and operators and users should
> be doing; still less about what legislators should or shouldn't be
> doing. I care about all those things, but the
On 06.09.2013 18:53, SM wrote:
At 06:04 06-09-2013, Martin Sustrik wrote:
So, what if an NSA guys comes in and proposes backdoor to be added to
a protocol? Is it even a valid interest? Does IETF as an organisation
have anything to say about that or does it remain strictly neutral?
Would anyone
Dave,
On 06.09.2013 18:58, Dave Crocker wrote:
On 9/6/2013 8:34 AM, Stephane Bortzmeyer wrote:
On Fri, Sep 06, 2013 at 08:20:17AM -0700,
Dave Crocker wrote
a message of 21 lines which said:
We currently do not have a concise catalog the basic 'privacy'
threats and their typical mitigations,
On Sep 6, 2013, at 8:07 AM, Eliot Lear wrote:
>
> On 9/6/13 3:04 PM, Martin Sustrik wrote:
>> So, what if an NSA guys comes in and proposes backdoor to be added to
>> a protocol? Is it even a valid interest? Does IETF as an organisation
>> have anything to say about that or does it remain stric
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/6/13 11:17 AM, Michael Richardson wrote:
> We just put our GPG fingerprint into the MEMO part of a vcard,
Actually, vCard has a KEY field:
http://tools.ietf.org/html/rfc6350#section-6.8.1
Peter
- --
Peter Saint-Andre
https://stpeter.im/
--
On 9/6/2013 10:46 AM, Ted Lemon wrote:
The threat model isn't really the NSA per se—if they really want to
bug you, they will, and you can't stop them, and that's not a
uniformly bad thing. The problem is the breathtakingly irresponsible
weakening of crypto systems that has been alleged here, a
On 9/6/13 4:47 AM, Adam Novak wrote:
> On 09/05/2013 08:19 PM, Brian E Carpenter wrote:
>> Tell me what the IETF could be doing that it isn't already doing.
>>
>> I'm not talking about what implementors and operators and users should
>> be doing; still less about what legislators should or sho
On Sep 6, 2013, at 9:55 AM, Dave Crocker wrote:
>
> In other words, the IETF needs to assume that we don't know what will work
> for end users and we need to therefore focus more on processing by end
> /systems/ rather than end /users/.
But we are also end users. I recall being laughed at 6 o
On 9/6/2013 11:42 AM, Dean Willis wrote:
On Sep 6, 2013, at 9:55 AM, Dave Crocker wrote:
In other words, the IETF needs to assume that we don't know what
will work for end users and we need to therefore focus more on
processing by end /systems/ rather than end /users/.
But we are also end use
On Sep 6, 2013, at 2:31 PM, Dean Willis wrote:
> What if they didn't say they were NSA guys, but just discretely worked a
> weakness into a protocol? What if they were a trusted senior member of the
> community?
If we have trusted senior members making false statements that can be shown to
be
I will be happy to participate in a pgp signing party.
Organized or not.
I suggest that an appropriate venue is during the last 15 minutes of the
newcomer welcome and the first 15 minutes of the welcome reception.
Because:
1) the WG-chairs and IESG will all be there, and a web of trust
st
On 09/06/2013 11:46 AM, Ted Lemon wrote:
> The threat model isn't really the NSA per se—if they really want to bug you,
> they will, and you can't stop them, and that's not a uniformly bad thing.
I disagree, or at least, I think that your statement conflates two
different threat models.
One kin
On Sep 6, 2013, at 2:51 PM, Phillip Hallam-Baker wrote:
> The issue is that smime email clients are more common so I would
> rather teach the smime doggie pgp like tricks than vice versa
The problem is getting your smime program to stop using CA keys and only use
your local key as a CA key. An
Could we do smime as well?
If we had a list of smime cert fingerprints it can be used for trust
reinforcement
The issue is that smime email clients are more common so I would
rather teach the smime doggie pgp like tricks than vice versa
Sent from my difference engine
On Sep 6, 2013, at 1:20 P
On 9/6/2013 11:38 AM, Noel Chiappa wrote:
> From: Spencer Dawkins
> I have to wonder whether weakening crypto systems to allow pervasive
> passive monitoring by "national agencies" would weaken them enough for
> technologically savvy corporations to monitor their competitors
On Fri, Sep 6, 2013 at 9:47 AM, Adam Novak wrote:
>
> One way to frustrate this sort of dragnet surveillance would be to reduce
> centralization in the Internet's architecture. Right now, the way the
> Internet works in practice for private individuals, all your traffic goes up
> one pipe to your
On Sep 6, 2013, at 2:06 PM, Måns Nilsson wrote:
>> Right, because there's no way the NSA could ever pwn the DNS root key.
> It is probably easier for NSA or similar agencies in other countries
> to coerce X.509 root CA providers that operate on a competetive market
> than fooling the entire intern
On 6 Sep 2013, at 21:32, Roger Jørgensen wrote:
> On Fri, Sep 6, 2013 at 9:47 AM, Adam Novak wrote:
>> The IETF focused on developing protocols (and reserving the necessary
>> network numbers) to facilitate direct network peering between private
>> individuals, it could make it much more expen
+Bruce Schneier (at least the email address published in his latest I-D), since
he should be at least aware of the discussion his callout has generated.
> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
> Ted Lemon
>
> On Sep 5, 2013, at 8:46 P
On 07/09/2013 08:55, Tim Chown wrote:
> On 6 Sep 2013, at 21:32, Roger Jørgensen wrote:
>
>> On Fri, Sep 6, 2013 at 9:47 AM, Adam Novak wrote:
>
>
>>> The IETF focused on developing protocols (and reserving the necessary
>>> network numbers) to facilitate direct network peering between private
Hi Dean,
At 11:31 06-09-2013, Dean Willis wrote:
What if they didn't say they were NSA guys, but just discretely
worked a weakness into a protocol? What if they were a trusted
senior member of the community?
Trust does not work well without accountability. There is less to
worry about if you
Ted,
On 07/09/2013 03:32, Ted Lemon wrote:
> On Sep 6, 2013, at 2:46 AM, SM wrote:
>> At 20:08 05-09-2013, Ted Lemon wrote:
>>> I think we all knew NSA was collecting the data. Why didn't we do
>>> something about it sooner? Wasn't it an emergency when the PATRIOT act
>>> was passed? We c
Subject: Re: Bruce Schneier's Proposal to dedicate November meeting to saving
the Internet from the NSA Date: Fri, Sep 06, 2013 at 11:46:17AM -0400 Quoting
Ted Lemon (ted.le...@nominum.com):
> On Sep 6, 2013, at 3:25 AM, Måns Nilsson wrote:
> > I do think that more distributed technoligies like
hum…
i did work on a DNS architecture that can be fully disconnected from
the "Internet" and still work with nodes within the visible topology.
Needs serious rework of DNSSEC and has some assumptions about topology
discovery - but it might be a basis for starting some discussio
How about a BCP saying conforming implementations of a wide-variety of
security-area RFCs MUST be open-source?
*ducks*
On Fri, Sep 6, 2013 at 2:34 PM, David Conrad wrote:
> On Sep 6, 2013, at 2:06 PM, Måns Nilsson
> wrote:
> >> Right, because there's no way the NSA could ever pwn the DNS root
On Sep 6, 2013, at 6:02 PM, Tim Bray wrote:
> How about a BCP saying conforming implementations of a wide-variety of
> security-area RFCs MUST be open-source?
So clearly we should do all our crypto on devices built out of 7400-series
logic. Hm, where has my old wire-wrap tool gone?
On 9/6/2013 10:17 AM, Michael Richardson wrote:
I will be happy to participate in a pgp signing party.
Organized or not.
I suggest that an appropriate venue is during the last 15 minutes of the
newcomer welcome and the first 15 minutes of the welcome reception.
Because:
1) the WG-chairs a
Hi Tim,
At 15:02 06-09-2013, Tim Bray wrote:
How about a BCP saying conforming implementations of a wide-variety
of security-area RFCs MUST be open-source?
A BCP is not needed to do that. It is already doable "but we [1]
know that you [2] are not going to do it".
Speaking of open source,
h
On Fri, Sep 6, 2013 at 3:34 PM, Ted Lemon wrote:
> On Sep 6, 2013, at 2:51 PM, Phillip Hallam-Baker wrote:
> > The issue is that smime email clients are more common so I would
> > rather teach the smime doggie pgp like tricks than vice versa
>
> The problem is getting your smime program to stop
On Fri, Sep 6, 2013 at 6:42 PM, Joe Touch wrote:
>
>
> On 9/6/2013 10:17 AM, Michael Richardson wrote:
>
>>
>> I will be happy to participate in a pgp signing party.
>> Organized or not.
>>
>> I suggest that an appropriate venue is during the last 15 minutes of the
>> newcomer welcome and the fir
On 9/6/2013 4:19 PM, Scott Brim wrote:
On Sep 6, 2013 3:34 PM, "Dave Crocker" mailto:d...@dcrocker.net>> wrote:
> To what end? Their poor uptake clearly demonstrates some basic
usability deficiencies. That doesn't get fixed by promotional efforts.
Or rather, as we've seen in other cases, peop
On Fri, 6 Sep 2013, Ted Lemon wrote:
> On Sep 6, 2013, at 6:02 PM, Tim Bray wrote:
> > How about a BCP saying conforming implementations of a wide-variety of
> > security-area RFCs MUST be open-source?
>
> So clearly we should do all our crypto on devices built out of 7400-series
> logic.
On Sep 6, 2013 3:34 PM, "Dave Crocker" wrote:
> To what end? Their poor uptake clearly demonstrates some basic usability
deficiencies. That doesn't get fixed by promotional efforts.
Or rather, as we've seen in other cases, people just don't see potential
benefits large enough to motivate them.
On Sep 6, 2013, at 6:42 PM, Joe Touch wrote:
> I've noted elsewhere that the current typical key-signing party methods are
> very weak. You should sign only the keys of those who you know well enough to
> claim you can attest to their identity.
This is a ridiculously high bar. The bar should
On 9/6/13 4:10 PM, Ted Lemon wrote:
> On Sep 6, 2013, at 6:42 PM, Joe Touch wrote:
>> I've noted elsewhere that the current typical key-signing party
>> methods are very weak. You should sign only the keys of those who
>> you know well enough to claim you can attest to their identity.
> This is a
On Fri, Sep 6, 2013 at 9:20 AM, Pete Resnick wrote:
> On 9/6/13 12:54 AM, t.p. wrote:
>
>> - Original Message -
>> From: "Phillip Hallam-Baker"
>> Cc: "IETF Discussion Mailing List"
>> Sent: Friday, September 06, 2013 4:56 AM
>>
>> The design I think is practical is to eliminate all UI
On Sep 6, 2013, at 8:21 PM, Melinda Shore wrote:
> when you vouch for someone's identity - in an authoritative
> trust system - you're also vouching for the authenticity of
> their transactions.
This is what I mean by "a high bar." Signing someone's PGP key should mean "I
know this person as X
On 9/6/13 5:09 PM, Ted Lemon wrote:
> This is what I mean by "a high bar." Signing someone's PGP key
> should mean "I know this person as X," not "this person is X."
I have no idea what "should" means in this context. It seems
to me, from looking at this discussion (as well as from other
discus
On 9/6/2013 5:10 PM, Ted Lemon wrote:
On Sep 6, 2013, at 6:42 PM, Joe Touch wrote:
I've noted elsewhere that the current typical key-signing party
methods are very weak. You should sign only the keys of those who you
know well enough to claim you can attest to their identity.
This is a ridi
Phillip Hallam-Baker wrote:
>On Fri, Sep 6, 2013 at 6:42 PM, Joe Touch wrote:
>
>>
>>
>> On 9/6/2013 10:17 AM, Michael Richardson wrote:
>>
>>>
>>> I will be happy to participate in a pgp signing party.
>>> Organized or not.
>>>
>>> I suggest that an appropriate venue is during the last 15 minu
On Sep 6, 2013 4:33 PM, "Roger Jørgensen" wrote:
>
> On Fri, Sep 6, 2013 at 9:47 AM, Adam Novak wrote:
> >
> > One way to frustrate this sort of dragnet surveillance would be to
reduce
> > centralization in the Internet's architecture. Right now, the way the
> > Internet works in practice for pri
> From: Scott Brim
> LISP does nothing for decentralization. Traffic still flows
> hierarchically
Umm, no. In fact, one of LISP's architectural scaling issues is that it's
non-hierarchical, so xTRs have neighbour fanouts that are much larger than
typical packet switches. In basic uni
On Sep 6, 2013 10:06 PM, "Noel Chiappa" wrote:
>
> > From: Scott Brim
>
> > LISP does nothing for decentralization. Traffic still flows
> > hierarchically
>
> Umm, no. In fact, one of LISP's architectural scaling issues is that it's
> non-hierarchical, so xTRs have neighbour fanouts t
On Sep 6, 2013, at 9:24 PM, Melinda Shore wrote:
> I'm not sure why
> "I know this person as " provides much more reliability
> than someone asserting their own identity.
Actually it's quite useful. It allows me to differentiate email coming from
someone I know as X from email coming from some
On Sep 6, 2013 9:10 PM, "Ted Lemon" wrote:
>
> On Sep 6, 2013, at 8:21 PM, Melinda Shore wrote:
> > when you vouch for someone's identity - in an authoritative
> > trust system - you're also vouching for the authenticity of
> > their transactions.
>
> This is what I mean by "a high bar." Signin
On Sep 6, 2013, at 10:18 PM, Scott Brim wrote:
> Dilution of trust is a problem with PGP. "I know this person as X" is way too
> lax if you want the system to scale.
It's naive to think that keys are any more trustworthy than this, because any
signature's trustworthiness is only as good as the
On 9/6/13 6:24 PM, Ted Lemon wrote:
> It's naive to think that keys are any more trustworthy than this,
> because any signature's trustworthiness is only as good as the
> trustworthiness of the individual who decides to sign it. If you
> trust a key signed by someone you don't know, but who someo
> From: Scott Brim
> The encapsulation is not much of an obstacle to packet examination.
There was actually a proposal a couple of weeks back in the WG to encrypt all
traffic on the inter-xTR stage.
The win in doing it in the xTRs, of course, is that you don't have to go
change all the
On Sep 6, 2013, at 10:35 PM, Melinda Shore wrote:
> I actually don't think that pgp is likely to be particularly
> useful as a "serious" trust mechanism, mostly because of
> issues like this.
It's not at all clear to me that "serious" trust mechanisms should be digital
at all. Be that as it ma
1 - 100 of 108 matches
Mail list logo
