Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Stephen Farrell <[e-mail]>]

On 05/12/2018 10:22, Bret Jordan wrote:
> I think we should be more open minded and look at the needs from a
> 360 degree deployment perspective. 

I think we should avoid marketing speak.

> The real power of the IETF is in
> looking at all the needs and requirements and designing solutions for
> them.

The IETF is sometimes at it's best when it says "no." This
is one of those cases.

> We should flesh this out. It seems like several people on this list
> so far have proposed options that might work. If we spent half as
> much time looking for a solution as we have trying to prevent a
> solution, we would probably be done by now.

All of the above was done, at length, and we got a result.
The TLS WG had no consensus to work on this topic.

S.


> 
> Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8
> ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however,
> the only thing that can not be unscrambled is an egg."
> 
>> On Dec 5, 2018, at 6:12 PM, Stephen Farrell
>> <[e-mail]> wrote:
>> 
>> 
>> 
>> On 05/12/2018 08:08, Bret Jordan wrote:
>>> Now this WG is finally starting to talk about a solution to a
>>> real problem and need.  We can either address the use case and
>>> need here in the IETF, or we can let the solutions be done else
>>> where. I would personally prefer we take this work item back and
>>> solve it here in the IETF.
>> 
>> #include <previous-discussions>
>> 
>> I would hope the WG not revisit this topic and see no new facts to
>> justify distracting the WG again. Forum shopping is not new -
>> rubber-stamping by ETSI or ANSI was explicitly proposed as a
>> putative reason to adopt draft-green and that did not result in
>> consensus to work on this topic despite the significant effort put
>> in by proponents. I'm also happy to say that I see no evidence that
>> the WG would reach a different conclusion as to lack of consensus.
>> 
>> FWIW, I view this discussion as being analogous to scratching an
>> itchy scab - despite our knowing it is unproductive to do so, some
>> IETF participants apparently can't resist poking at the wound:-(
>> 
>> S.
>> 
>>> 
>>> Finally, remember, you may not like the use case or need, but
>>> that does not mean the use case is not valid and needed.
>>> 
>>> Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0
>>> 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw,
>>> however, the only thing that can not be unscrambled is an egg."
>>> 
>>>> On Dec 5, 2018, at 1:18 AM, Tony Arcieri <[e-mail]> 
>>>> wrote:
>>>> 
>>>> On Sun, Dec 2, 2018 at 3:36 PM Nico Williams
>>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> I'm not a fan of systems like this, but I believe for
>>>>> security reasons they should be designed in such a way that
>>>>> only the confidentiality of traffic is impacted, and a
>>>>> "visibility" system isn't able to leverage the decrypted
>>>>> traffic to resume decrypted sessions and thereby impersonate
>>>>> clients.
>>>> 
>>>> Any key escrow system will have this property.  Given the
>>>> session keys (or a way to recover them) you can resume
>>>> decrypted sessions.
>>>> 
>>>> Wouldn't escrowing only the client/server application traffic 
>>>> secrets (instead of keys higher in the schedule) avoid this 
>>>> problem? These keys would permit the one capability
>>>> "visibility" appliance vendors allege to care about: traffic
>>>> decryption, without permitting others like session resumption.
>>>> 
>>>> The most obvious escrow design requiring no changes to the
>>>> clients is to use a static eDH key on the server-side.  The
>>>> next most obvious such design is to have the server talk to the
>>>> escrow agent.
>>>> 
>>>> It seems like with an out-of-band escrow agent, the traffic
>>>> secrets could be escrowed with no changes to TLS.
>>>> 
>>>> -- Tony Arcieri _______________________________________________
>>>> TLS mailing list [e-mail] 
>>>> https://www.ietf.org/mailman/listinfo/tls
>>> 
>>> 
>>> 
>>> _______________________________________________ TLS mailing list
>>>  [e-mail] https://www.ietf.org/mailman/listinfo/tls
>>> 
>> <0x5AB2FAF17B172BEA.asc>
> 
>