Hi Rich,
When I say “authoritative”, I mean it in the true TLS sense, in the way that I
believe the ECH draft also suggests and requires.
In other words, the middlebox serves a cert to the client that is
cryptographically valid for the said public name of the client facing server.
How can that
I think he is.
In order to pull off your attack, you need to convince a CA that you have their
identity, so you can bind an arbitrary public key to it, then publish it.
But if you can attach an arbitrary public key to someone else's identity,
you're going to use that for MITM and not the DoS yo
Victor, actually, I take it back - you may be right in that last point. Need
to think.
Regards,
Uri
> On Oct 7, 2022, at 14:59, Blumenthal, Uri - 0553 - MITLL
> wrote:
>
>
>>> On Oct 7, 2022, at 14:42, Viktor Dukhovni wrote:
>>>
>>> On Fri, Oct 07, 2022 at 06:19:15PM +, Blumenthal,
> On Oct 7, 2022, at 14:42, Viktor Dukhovni wrote:
>
> On Fri, Oct 07, 2022 at 06:19:15PM +, Blumenthal, Uri - 0553 - MITLL
> wrote:
>
>> Then publish the certificate. Then the victim is unable to read email
>> encrypted to her. A DoS that costs the attacker very little,
>> practically no
On Fri, Oct 07, 2022 at 06:19:15PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> Then publish the certificate. Then the victim is unable to read email
> encrypted to her. A DoS that costs the attacker very little,
> practically nothing.
What victim is that?
All the PoP does is make it harder to
John Gray writes:
>You can replay the CSR and get the certificate request by the original
>party signed by whatever CA you want, but would that do you any good if
>you don't have the private key?
>That's exactly the point, which others have also made in the thread. Yes, you
>can do this, but
> >You can replay the CSR and get the certificate request by the original party
> >signed by whatever CA you want, but would that do you any good if you don't
> >have the private key?
>
> That's exactly the point, which others have also made in the thread. Yes,
> you
> can do this, but then
> > I mean what actual attack that's been actively exploited in the real world
> > will use of PoP prevent?
> > We've been shipping raw PKCS #10's around for decades (with no PoP) without
> > causing the collapse of civilisation.
>
> Peter, just wanted to point out that this is one of the most h
John Gray writes:
>You can replay the CSR and get the certificate request by the original party
>signed by whatever CA you want, but would that do you any good if you don't
>have the private key?
That's exactly the point, which others have also made in the thread. Yes, you
can do this, but then
> > I mean what actual attack that's been actively exploited in the real world
> > will use of PoP prevent?
> > We've been shipping raw PKCS #10's around for decades (with no PoP) without
> > causing the collapse of civilisation.
>
> Peter, just wanted to point out that this is one of the most
On Fri, 2022-10-07 at 17:30 +, Peter Gutmann wrote:
von Oheimb, David
mailto:david.von.ohe...@siemens.com>> writes:
Peter, the argument you gave below:
I mean what actual attack that's been actively exploited in the real world will
use of PoP prevent?
We've been shipping raw PKCS #10's arou
-Original Message-
From: Peter Gutmann
Sent: Friday, October 7, 2022 1:31 PM
To: von Oheimb, David ;
Mike.Ounsworth=40entrust@dmarc.ietf.org; John Gray ;
tim.holleb...@digicert.com; tomas.gustavs...@keyfactor.com
Cc: morgan...@dataio.com; sp...@ietf.org; tls@ietf.org
Subject: Re: [
Blumenthal, Uri - 0553 - MITLL writes:
>Peter, "Compromised" in the context must necessarily mean "someone stole the
>key", because if someone "broke the crypto" - then none of the certs issued
>by that CA is worth the weight of electrons that carried it.
"Compromised" meant (at the time, I was t
Tomas Gustavsson writes:
>I'd like to add that adding a challenge-response POP need to be built into
>protocols as well, not only in CSR formats/specification. Only adding a
>method for this to PKCS#10, without also specifying how it is to be used in
>ACME, CMP, EST and SCEP will most likely wrea
* So what I've learned from Tomas' responses and from another exchange is
that there are two types of CT logs.
Two types of CT log *entries.* A single log can have both items. Recall that
both pre-cert and issued are certificates.
___
TLS mailing
von Oheimb, David writes:
>Peter, the argument you gave below:
>
>> I mean what actual attack that's been actively exploited in the real world
>> will use of PoP prevent?
>> We've been shipping raw PKCS #10's around for decades (with no PoP) without
>> causing the collapse of civilisation.
>
>a
I'd like to add that adding a challenge-response POP need to be built into
protocols as well, not only in CSR formats/specification. Only adding a method
for this to PKCS#10, without also specifying how it is to be used in ACME, CMP,
EST and SCEP will most likely wreak total havoc.
/Tomas
Whether it is really worth requiring a PoP for keys that do not support
signatures, when facing the - likely - drawback that a single round trip will
no more be sufficient, is certainly debatable.
I tend to think "yes" for both reasons mentioned below:
* As Tim pointed out, omitting the PoP check
So what I've learned from Tomas' responses and from another exchange is that
there are two types of CT logs.
* The first type of log receives the TBSCertificate containing the CT poison
extension, and logging this preliminary cert cannot be delayed because the
final cert depends on the SCT resp
Peter, "Compromised" in the context must necessarily mean "someone stole the
key", because if someone "broke the crypto" - then none of the certs issued by
that CA is worth the weight of electrons that carried it.
Oh, and could you please be a little more constructive?
--
V/R,
Uri
On 10/7/2
It largely isn’t necessary. I like proof of possession for issuance, but
mostly just to avoid nuisances. But this topic is widely misunderstood. I
think if you took a poll of PKI professionals, you’d find that lots of them
erroneously believe that issuance of a certificate certifies that the
Tim Hollebeek writes:
>There’s also the problem that there’s no standard for secure proof of
>possession for revocation, despite a number of us calling for one for years.
This is one of the 8,000 (approximately) great unresolved PKIX disagreements
where about half of PKIX thought revocation shou
* Client <-> Middlebox <-> Client-facing server <-> Backend server
* With "Middlebox" really meaning a middlebox like a firewall or similar.
The middlebox is not allowed to modify traffic between the client and the
server. Doing so would mean that the packets the client sent are not t
It largely isn't necessary. I like proof of possession for issuance, but
mostly just to avoid nuisances. But this topic is widely misunderstood. I
think if you took a poll of PKI professionals, you'd find that lots of them
erroneously believe that issuance of a certificate certifies that the
> Shouldn't it be possible to delay the addition to the CT log until the
> confirmation (which may be based on decrypting the new cert or any other
> challenge) by the EE has arrived at
> the CA?
Sorry, any other challenge, for sure it can be done. If such a step can be
built into the ACME pro
> Shouldn't it be possible to delay the addition to the CT log until the
> confirmation (which may be based on decrypting the new cert or any other
> challenge) by the EE has arrived at
> the CA?
CT have two different modes. One where the final certificate is published to
the CT log. This one
26 matches
Mail list logo
