Not an argument in favor of the proposal, but the issue with firewall certs
is not that we would want to override local security policy, but that
firewall certs *can* in principle override local security policy, and in
principle DANE could be used to prevent that. What is meant by a firewall
cert
Unjust certificates can be bought for 150,- $ in the darknet which makes TLS
snake-oil. And you never know if the internet provider is hostile or hacked.
So we should act in the favor of end-users. If we don't have the position to
make DANE mandatory, yet, we should at least try to encourage bro
On Tue, Oct 16, 2018 at 10:02 AM Rene 'Renne' Bartsch, B.Sc. Informatics
wrote:
> Unjust certificates can be bought for 150,- $
[citation-needed]
https://xkcd.com/285/
I'm sure if you could produce such a certificates, the root programs would
be happy to investigate how it was caused to be is
Can you provide a citation for that statement? Not doubting you,
particularly, but this is news to me, and probably to some others on this
list, if true.
On Tue, Oct 16, 2018 at 4:01 PM Rene 'Renne' Bartsch, B.Sc. Informatics
wrote:
> Unjust certificates can be bought for 150,- $ in the darkne
I haven't found the article with 150,- $, yet, but this isn't good either:
https://www.bankinfosecurity.com/study-finds-custom-market-for-bogus-tls-certificates-a-10680
and Mozilla makes it worse:
https://blog.mozilla.org/security/2018/10/10/delaying-further-symantec-tls-certificate-distrust/
On Tue, Oct 16, 2018 at 11:00 AM Rene 'Renne' Bartsch, B.Sc. Informatics
wrote:
> I haven't found the article with 150,- $, yet, but this isn't good either:
>
>
> https://www.bankinfosecurity.com/study-finds-custom-market-for-bogus-tls-certificates-a-10680
>
> and Mozilla makes it worse:
>
>
> ht
Hi Simon,
I don't think we specified a concrete recommendation, but I think the
answer is probably no. The reason is that:
(a) a resumed handshake is very cheap, so it's not really saving CPU
(b) the server's first flight is small in resumption, so amplification
isn't much of an issue.
Maybe I'm
@Florian
The document is about the SSL 2.0 security deficiencies, particularly the
ones that brought its prohibition. The solutions to these deficiencies
might also have their own problems, as it's often the case in security
related topics which look like a never-ending debate (a problem, a
soluti
Hi all--
I'm disappointed in how long this WG is taking to get
draft-ietf-tls-dnssec-chain-extension out the door.
I agree with both Tom and Viktor that the current draft seems to be
misaligned between the goals and the stated scope.
I wanted the draft to be done by now because i think it will b
All,
This is the working group last call for the "Issues and Requirements for SNI
Encryption in TLS" draft available at
http://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/. Please review
the document and send your comments to the list by 2359 UTC on 31 October 2018.
Thanks your cha
All,
I ran I-D nits before hitting the appropriate buttons to place this draft in
WGLC. I figured we could address the following before we send the draft to Ben:
== Outdated reference: draft-ietf-tls-tls13 has been
published as RFC 8446
== Outdated reference: A later version (-14) e
> On Oct 16, 2018, at 6:16 PM, Daniel Kahn Gillmor
> wrote:
>
> Just a quick summary of my understanding:
>
> * The existence of a pin only requires that the service operator
> maintain the ability to respond to this extension in the future -- it
> doesn't require specific keys, or even
This is a pretty good piece of information that is very nearly done.
Regarding the idnits results, DoH is done, but DTLS and QUIC are still
a way off. Would we prefer publication with downref or waiting? For
me, this depends somewhat on the maturity of the documents that depend
on this. I'd be
Hi from DNS land.
>pinning, but i won't go too far into the weeds here. Just a quick
>summary of my understanding:
>
> * The existence of a pin only requires that the service operator
> maintain the ability to respond to this extension in the future -- it
> doesn't require specific keys, or e
On Tue, Oct 16, 2018 at 06:16:22PM -0400, Daniel Kahn Gillmor wrote:
>
> I agree with both Tom and Viktor that the current draft seems to be
> misaligned between the goals and the stated scope.
I also agree that there is some misalignment of this nature.
My attempt at a root cause analysis would
> On Oct 16, 2018, at 9:07 PM, John Levine wrote:
>
> Something like "require DANE certs until time N" should be plenty.
>
> Remember that you can also unpin by publishing a signed NXDOMAIN or
> NODATA. Since you need to have DNSSEC working to get the pin in the
> first place, that doesn't s
On Tue, 16 Oct 2018, Daniel Kahn Gillmor wrote:
That said, it sounds like negotiating the details of how to do this
pinning is the main blocker, and i'm sick of this proposal being blocked
(because i want it for "greenfield" implementations last year).
Imagine how sick I will be when I try to
On Wed, Oct 17, 2018 at 01:46:20AM -0400, Paul Wouters wrote:
> On Tue, 16 Oct 2018, Daniel Kahn Gillmor wrote:
>
> > That said, it sounds like negotiating the details of how to do this
> > pinning is the main blocker, and i'm sick of this proposal being blocked
> > (because i want it for "greenf
18 matches
Mail list logo
