Would it be possible to use delegated credentials to address lawful
intercept concerns, similar to eTLS?
Basically, the server operator would issue a delegated credential to
someone who has to decrypt or modify the traffic after intercepting
it, without having to disclose that backdoor in
* Paul Wouters:
> On Wed, 21 Nov 2018, Stephen Farrell wrote:
>
>>> We currently permit >1 RR, but
>>> actually
>>> I suspect that it would be better to try to restrict this.
>>
>> Not sure we can and I suspect that'd raise DNS-folks' hackles,
>> but maybe I'm wrong.
>
> I think the SOA record is
* Nancy Cam-Winget:
> @IETF99, awareness was raised to some of the security WGs (thanks
> Kathleen ☺) that TLS 1.3 will obscure visibility currently afforded in
> TLS 1.2 and asked what the implications would be for the security
> solutions today.
>
On 10/13/2017 02:45 PM, Stephen Farrell wrote:
So the problems with that are numerous but include:
- there can be >1 carol, (and maybe all the carols also need to
"approve" of one another), if we were crazy enough to try do
this we'd have at least:
- corporate outbound snooper
* BITS Security:
> Deprecation of the RSA key exchange in TLS 1.3 will cause significant
> problems for financial institutions, almost all of whom are running
> TLS internally and have significant, security-critical investments in
> out-of-band TLS decryption.
>
> Like many enterprises,
* Hubert Kario:
> those secret keys are on the client machines and they will stay on client
> machines
>
> making it hard to extract master key from process memory is just security
> through obscurity, not something that will stop a determined attacker
I think extracting the master key is
On 01/04/2016 12:59 PM, Hubert Kario wrote:
> On Monday 28 December 2015 21:08:10 Florian Weimer wrote:
>> On 12/21/2015 01:41 PM, Hubert Kario wrote:
>>> if the rekey doesn't allow the application to change authentication
>>> tokens (as it now stands), then rek
On 12/28/2015 10:09 PM, Salz, Rich wrote:
>> When the key is changed, the change procedure should involve new randomness.
>
> I don't think this is necessary, and I don't think the common crypto
> expertise agrees with you, either. But I am not a cryptographer, maybe one of
> the ones on this
On 01/04/2016 01:19 PM, Hubert Kario wrote:
>> Dealing with this during the initial handshake is fine. But
>> supporting direction-switching after that is *really* difficult.
>
> yes, this is a bit more problematic, especially for one-sided transfers.
> For example, when one side is just
On 12/28/2015 09:11 PM, Eric Rescorla wrote:
>> You still have the added complexity that during rekey, you need to
>> temporarily switch from mere sending or receiving to at least
>> half-duplex interaction.
>>
>
> That's not intended. Indeed, you need to be able to handle the old key
> in order
On 12/21/2015 01:41 PM, Hubert Kario wrote:
> if the rekey doesn't allow the application to change authentication
> tokens (as it now stands), then rekey is much more secure than
> renegotiation was in TLS <= 1.2
You still have the added complexity that during rekey, you need to
temporarily
wild appear to be harmless in the sense that
they are not due to attacks, but due to interoperability failures (due
to not enabling mandatory-to-implement cipher suites, self-signed
certificates, incomplete certificate chains, or just bugs).
--
Florian Weimer / Red Hat Prod
12 matches
Mail list logo
