* Hubert Kario:
> On Tuesday 28 July 2015 16:01:55 Viktor Dukhovni wrote:
>> In that case, it should be said that a client MUST NOT advertise
>> TLS 1.3 unless it offers at least one of the TLS 1.3 MTI ciphers
>> (or perhaps less restrictive at least one TLS 1.3 compatible cipher).
>
> MTI does no
* Viktor Dukhovni:
> In that case, it should be said that a client MUST NOT advertise
> TLS 1.3 unless it offers at least one of the TLS 1.3 MTI ciphers
> (or perhaps less restrictive at least one TLS 1.3 compatible cipher).
Or the server should negotiate TLS 1.2 instead.
Servers should already
d or not) might an attractive
option. Except that Mozilla could claim its self-learning trust store
is just magically growing root certificates in the sense of such a
requirement (although such certificates are necessarily intermediate,
otherwise it woul
On 08/31/2015 05:54 PM, Martin Thomson wrote:
> On 31 August 2015 at 05:02, Florian Weimer wrote:
>> MUST NOT automatically complete incomplete chains
>
> Um, no. I realize that this is a feature that is hard for others to
> replicate, but being able to reach sites is importa
ould be SHOULD, at most."
Using full-duplex TCP, it's difficult to get a fatal alert over the wire
if you want to close the connection immediately:
<http://www.ietf.org/mail-archive/web/tls/current/msg08342.html>
The workarounds proposed in that thread may not be always practical
On 09/15/2015 06:29 PM, Nico Williams wrote:
> On Tue, Sep 15, 2015 at 03:18:30PM +0200, Florian Weimer wrote:
>> On 09/12/2015 10:49 PM, Eric Rescorla wrote:
>>> Issue: https://github.com/tlswg/tls13-spec/issues/242
>>>
>>> In https://github.com/tlswg/tls
On 09/16/2015 01:51 PM, Henrik Grubbström wrote:
> On Wed, Sep 16, 2015 at 12:02 PM, Florian Weimer wrote:
>> On 09/15/2015 06:29 PM, Nico Williams wrote:
> [...]
>>>
>>> But if you have a fatal error you'll be closing immediately anyways.
>>> Does s
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
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 swi
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 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), the
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 l
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 sendin
* RFC Errata System:
> Corrected Text
> --
>o The root certificate authority keys are overexposed. The server
> sends only one certificate signed by a root certificate authority,
> which means a frequent use of this authority keys for signing new
> certificates.
* 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
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 certific
* 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 proba
* 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, financia
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
* 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.
> https://tools.ietf.org/html/draft-camwinget-tls-
20 matches
Mail list logo
