On 8 October 2013 22:14, Stephen Farrell wrote:
>
>
> Hi,
>
> Steve's mail argues for the current IETF position that
> mandatory-to-implement (MTI) is the correct target IETF
> specifications.
>
> Some folks (me included to be honest) wonder if the current
> situation argues for raising the bar th
Hi Stephen,
I'll respond in line to clarify my initial email.
Thanks,
Kathleen
-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
Sent: Tuesday, October 08, 2013 9:34 PM
To: Moriarty, Kathleen; Peterson, Jon; perpass
Subject: Re: [perpass] mandatory-to-implement
Ben,
O...
How about a distinction in compliance? That is, you can say you comply
to RFC xyzw if you implement it, but to say you _securely_ comply, you
have to switch on the MTUFS (mandatory to use for security) and switch
off MTNUFS (mandatory to not use for security) features in the RFC.
Some
On 9 October 2013 16:55, Stephen Kent wrote:
> Ben,
>
>> O...
>>
>> How about a distinction in compliance? That is, you can say you comply
>> to RFC xyzw if you implement it, but to say you _securely_ comply, you
>> have to switch on the MTUFS (mandatory to use for security) and switch
>> off MTNU
Stephen,
Thanks for creating a new thread to discuss this topic. It's a good
starting point for
an important discussion.
I think MTU (vs. MTI) is a very hard argument to make, for several reasons,
some of which I noted in my response to Dean.
Internet protocols are used in a very, very wide
Ben,
...
It's all about incentives. Why would anyone care right now whether an
RFC is a standard or not? No-one beats them up for complying with
non-standards. Or even failing to comply with standards.
That does not seem to be uniformly true. Some folks who purchase
equipment have been know to r
On 9 October 2013 18:33, Stephen Kent wrote:
>> We need to make these things visible (and I don't mean "show a
>> padlock", btw, I mean the kind of visibility we propose for
>> Certificate Transparency, namely, if it doesn't work right, you don't
>> connect).
>
> Ben, please stop pushing CT as the
Ben,
Sorry if I misinterpreted your comment in this context.
Steve
...
Ben, please stop pushing CT as the solution for everything; it's become
more than tiresome.
I was not pushing CT in any way! I was pushing for visibility that is
not a padlock, since we know that doesn't work.
On 9 October 2013 18:33, Stephen Kent wrote:
> Ben,
> ...
>
>> It's all about incentives. Why would anyone care right now whether an
>> RFC is a standard or not? No-one beats them up for complying with
>> non-standards. Or even failing to comply with standards.
>
> That does not seem to be uniform
Well from a SIP perspective we have always had mandatory to implement TLS in
any number of specifications but in practice no one uses it. No one. No one
cares.
-Original Message-
From: perpass-boun...@ietf.org [mailto:perpass-boun...@ietf.org] On Behalf
Of Stephen Farrell
Sent: Tuesday,
* Mike Demmers wrote:
>TThe basic concept of default deny for encrypted emails only seems very
>'right' to
>me, because if you are going to the trouble to do this, and handle things like
>key exchanges, that communication must be pretty special to begin with. Why
>would
>you want 'just anyone' to
For PSTN replacement deployments in effectively private networks, the case
for transport-level security is unconvincing, sure.
To Steve Kent's earlier point, documents that explain why strong security
is a best practice for particular environments would do better than a
blanket assertion that SIP
On 10/09/2013 11:44 PM, Peterson, Jon wrote:
> A BCP could
> however provide the necessary motivation for using TLS in the situations
> where it will actually help, and the recent revelations make that case
> rather eloquently.
I'm confused by that a bit - given the GCHQ/Belgacom example, in
whi
I suspect your confusion surrounds who exactly would be helped and what
that help would be. All I was saying is that there are deployments whose
operators and implementers don't perceive the need for such help, and that
we're unlikely to persuade them of it. Making TLS MTU for SIP would have
no ap
On 10/10/2013 12:21 AM, Peterson, Jon wrote:
>
> I suspect your confusion surrounds who exactly would be helped and what
> that help would be. All I was saying is that there are deployments whose
> operators and implementers don't perceive the need for such help,
I agree with that.
> and that
On 10/09/2013 09:55 PM, Richard Shockey wrote:
> Well from a SIP perspective we have always had mandatory to implement TLS in
> any number of specifications but in practice no one uses it. No one. No one
> cares.
BTW - thanks Rich - I think saying what really happens is very helpful.
Pretend
Hi Steve,
On 10/09/2013 06:22 PM, Stephen Kent wrote:
> Stephen,
>
> Thanks for creating a new thread to discuss this topic. It's a good
> starting point for
>
> an important discussion.
I agree its important.
> I think MTU (vs. MTI) is a very hard argument to make, for several reasons,
> som
+1 .. unlikely is a mild word. I would have probably used the words never
persuade them.
-Original Message-
From: Peterson, Jon [mailto:jon.peter...@neustar.biz]
Sent: Wednesday, October 09, 2013 7:21 PM
To: Stephen Farrell; Richard Shockey; 'perpass'
Subject: Re: [perpass] mandatory-to-i
> For me, the question is: Nobody uses SIP/TLS now. Using SIP/TLS
> would add some value. How can we make it more likely they do use
> SIP/TLS?
Define "nobody," please. Microsoft Lync uses SIP/TLS by default. That must
be more than "nobody."
-- Christian Huitema
19 matches
Mail list logo
