On Thu, Nov 8, 2018 at 9:31 PM Ryan Carboni wrote:
> On Thursday, November 8, 2018, Eric Rescorla wrote:
>
>> It's also worth noting that in practice, many sites are served on
>> multiple CDNs which do not share keying material.
>>
>
> Encrypting common knowledge is cargo cult fetishism for
> On Nov 9, 2018, at 11:52 AM, Yoav Nir wrote:
>
>> Nor have I, and I rather think that introducing fixed-(EC)DH ciphers into
>> TLS was a mistake, and glad to see them gone in TLS 1.3.
>
> FWIW RFC 8422 also deprecates them for TLS 1.2 and earlier.
Great! Thanks. I see that in:
5.5.
> On 9 Nov 2018, at 13:40, Viktor Dukhovni wrote:
>
>> On Nov 9, 2018, at 1:19 AM, Peter Gutmann wrote:
>>
>>> Well, ECDH keys (not really ECDSA) can do key agreement, and EC keys can be
>>> used for encryption with ECIES.
>>
>> Sure, in theory, but in practice I've never seen an (EC)DH
> I'm somewhat dismayed by the firm recommendation to use the HMAC
> mechanism,
Yeah, this could probably be loosened somewhat.
> which doesn't seem particularly robust.
It's designed to be fairly robust. Of course, we may have done things
wrong.
> Offhand, it seems like replays are possible
On 2018-11-08 20:41 -0500, Jim Reid wrote:
On 8 Nov 2018, at 08:44, Ryan Carboni wrote:
This might be a radical proposal, but maybe the certificate hash could be
placed in a DNS TXT record.
[..]
If you need to put this hash in the DNS, you might as well get a type code
assigned for
Hi David,
I couldn't find any description of the threat model involved here, nor
could I find any analysis of the security against that model. Without
that, I can't really say whether this is right or not. For instance,
there is specific mention of the certificate status request extension,
but
