I’m worried about the fact that this means a certificate that was issued for
and intended to be used by a particular IP address is now potentially usable on
any arbitrary IP address via this behavior. Though I haven’t thought it all
the through yet, it seems to me to be likely that there are us
reading and thinking this through. It’s an
interesting use case.
-Tim
From: Erik Nygren
Sent: Thursday, July 28, 2022 7:14 PM
To: Tim Hollebeek
Cc: David Benjamin ; TLS@ietf.org
Subject: Re: [TLS] Representing IP addresses in SNI -- proposed draft
The use-case that may increase IP
Also, the amount of work necessary to make Certificate Transparency work with
three day certificates is probably not worth the effort.
It's not that you can't do it ... the easiest way is to break the 1-1
correspondence between SCTs and certificates, and make allowances for issuing a
series of
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
> > 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
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
I wish people would stop citing the Cloudflare example as if something
nefarious is going on there. It is absolutely, 100% false that the identity in
a certificate should identify who Cloudflare is getting the certificate on
behalf of. Cloudflare requests the certificates, holds the keys, and
Honestly, people can blame all sorts of things for the OCSP stapling problems,
but there was nothing inherently wrong with the approach. The implementations
were just pretty poor due to issues Hubert Kario correctly outlined. In
general,
the needs of server operators and maintainers of server so
SCTs have always seemed surprisingly large to me, and it has always seemed
like there should be a more compact representation that has the same security
properties, but I've never found the time to look more closely at it. If
someone
does have the time, figuring out how to reduce the size of SCTs
I wish root programs accepted roots from new CAs at a speed where a one year
old dictionary would be a problem. Cross-certificates are already generally
required
for several years, on average. However, cross-certificates are not ideal, as
they increase
server configuration problems and chain
The WebPKI has a few features that enable this, which other PKIs really should
consider adopting. It's one of the few fully transparent PKIs I'm currently
aware of,
where all of the intermediate and root CAs, and most of the end entity
certificates
are publicly known and available.
For those re
When considering caching large public keys for TLS (or other protocols), please
make sure the security considerations section carefully considers whether the
proposed mechanism leaks information about whether the client has previously
contacted the server and possibly how recently, etc.
-T
So, I was talking to Mike Ounsworth about similar issues at the PQC hackathon.
I would like us to agree on what a cocktail napkin description of the desired
PQC end state for all the affected protocols looks like. I think that would be
very helpful, and this thread looks like it’s starting to
details, even at a very high level.
If it changes in the future due to new events or analysis, that’s ok too.
-Tim
From: Bas Westerbaan
Sent: Monday, November 6, 2023 1:14 PM
To: Tim Hollebeek
Cc: John Mattsson ; TLS@ietf.org
Subject: Re: [TLS] What is the TLS WG plan for quantum
I personally think this point is important enough to be made explicitly instead
of implicitly.
If we want to communicate loudly and clearly that post-quantum cryptography is
NEVER coming to TLS 1.2, we need to explicitly say that.
Otherwise people will say “I know you said TLS 1.2 was fro
Most people in the positions you describe are not experts themselves, but rely
on the recommendations and analysis of prominent industry groups because they
know that that is likely to produce better answers than every IT practitioner
trying to determine the answer themselves.
The best and b
So, this has been discussed extensively at the CA/Browser forum, for obvious
reasons.
In my mind, it is not so important to identify and define and implement an
alternative hash.
What *is* important is that the protocol and associated software is able to
support a smooth transition period where p
ating with clients who
had different certificate capabilities. It isn't a bad thing that both
approaches exist.
-Tim
> -Original Message-
> From: Andrei Popov [mailto:andrei.po...@microsoft.com]
> Sent: Friday, December 15, 2017 12:25 PM
> To: Tim Hollebeek ; Ilari Lius
> I'm not sure I agree renumbering is the right reaction, though I don't
> object to
> that. This could be a case where it's overall better that those specific
> devices
> suffer breakage, and hopefully then do get firmware updated to support
> TLS1.3 or TLS-without-extended-random-or-dual-ec
>
> The webpki is changing dramatically. The amount of CAB/forum violations
> seems to be increasing, partially as a result of these violations getting
> exposed
> by certificate transparancy and perhaps partially because of the financial
> strain
> caused by the free LetsEncrypt.
Uniformed specul
I generally really like it.
My only comment is about the use of a zero byte as a separator in a string
(4.2.2).
There are commonly used languages where this is likely to lead to
implementation bugs, causing the signature to be computed over a shorter length
than expected.
While I dou
Making things more complicated with no obvious benefit just makes things
more complicated.
I oppose adding two bytes for some nebulous future purpose.
-Tim
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of James Cloos
> Sent: Wednesday, May 16, 2018 6:20 PM
> To
I’m actually fine with that. You have to consider P_{extension implemented and
used}.
Different people will disagree about the value of P.
-Tim
From: Paul Wouters [mailto:p...@nohats.ca]
Sent: Thursday, May 17, 2018 8:18 PM
To: Tim Hollebeek
Cc: James Cloos ; Ted Lemon ;
Subject
I think there’s room for two people in front of the steamroller. And I have a
towel. How many votes does that get me?
-Tim
From: Melinda Shore [mailto:melinda.sh...@nomountain.net]
Sent: Thursday, May 17, 2018 9:21 PM
To: Tim Hollebeek
Cc: Paul Wouters ;
Subject: Re: [TLS] TLS
One of the things we found out with CAA is that this extremely optimistic view
of the support for unknown RR types by large hosting providers is not
accurate.
-Tim
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Paul Wouters
> Sent: Monday, July 2, 2018 11:53
Unfortunately, I haven’t had time to review the document, but +1 for
interesting problem, and +1 for anything Richard writes as a good starting
point, even if I haven’t read it.
-Tim
From: TLS On Behalf Of Hugo Krawczyk
Sent: Wednesday, July 18, 2018 7:13 PM
To: Richard Barnes
Cc:
Sub
I think this is a good summary. I want to support this sort of effort, in part
because it's very similar to some other ideas my boss and I were pushing about
five years ago. Something similar to this would solve, but also cause, lots of
problems. It's not clear whether the net result is bette
I agree with this.
Also, the poll that was done at the TLS session is prone to being
misunderstood.
There was a poll about a preference between the two drafts, but the question
of
whether either of the drafts is necessary was skipped. I don't think it's fair
to do
a presumptive close on that u
> And thinking about the decade+ WebPKI SHA-1 to SHA-2 transition, I do not
> think the main factor was long approval timelines, need to do rigorous
> analysis, or need for rigorous discussion.
So, the WebPKI SHA-1 to SHA-2 transition was a tiny little corner of the SHA-1
to SHA-2 transition. It
My personal feelings on pure vs composite are actually the union of several
previous comments:
1. Like EKR, I actually have a weak preference for composite, all other
things being equal. Failures happen and I like backup mechanisms
when they are relatively affordable and can be afforded.
I would like to thank the chairs in advance for all the hard and thankless work
they just volunteered for. It is desperately needed and I truly appreciate it.
-Tim
> -Original Message-
> From: Sean Turner
> Sent: Friday, October 25, 2024 8:31 AM
> To: TLS List
> Subject: [TLS] Changing
Agree completely, the only thing that can go wrong with this draft is scope
creep.
-Tim
From: Deirdre Connolly
Sent: Wednesday, October 23, 2024 3:22 PM
To: Alicja Kario
Cc: Bas Westerbaan ;
Subject: [TLS] Re: ML-DSA in TLS
I would rather have a separate I-D for anything beyond M
+1 to choosing reasonable and consistent names that make sense, instead of
being overly concerned with whether they exactly replicate the implementation.
-Tim
From: David Benjamin
Sent: Thursday, October 17, 2024 11:33 AM
To:
Subject: [TLS] Re: X25519MLKEM768 in draft-kwiatkowski-tls-ecdh
Because there are other drafts for the other ideas.
Standardizing how to do ML-DSA in TLS in no way “favors” it or otherwise
indicates any sort of exclusivity. There is nothing in the draft that precludes
other approaches.
-Tim
From: Andrey Jivsov
Sent: Friday, November 15, 2024 12:
One of the things we need to be honest with ourselves about is that telling
people not to do it won’t prevent them from doing it.
So this decision is saying that WHEN people decide do PQC with TLS 1.2, they
will be doing so without IETF guidance about how to do it. If this is the path
we cho
+1
From: Salz, Rich
Sent: Sunday, December 15, 2024 12:56 PM
To: Tim Bray ; Eric Rescorla
Cc: tls@ietf.org
Subject: [TLS] Re: Fwd: New Version Notification for
draft-farrell-tls-pqg-00.txt
If that draft is useful, it probably belongs in the UTA working group, not TLS.
I would expres
Yes, the thread on this draft got hijacked by a completely off-topic discussion
about composite and hybrid.
To be clear, the draft says absolutely nothing about either of those two
topics, and to be even more clear, does not at all imply in any way that pure
ML-DSA is superior or is the only
Consensus has nothing to do with number of votes. We don’t vote, and we
shouldn’t. We also shouldn’t disadvantage those who can’t attend sessions live
for whatever reason. The existing rules cover this pretty well, imo.
The reason we appoint technically competent chairs and directors, and tho
38 matches
Mail list logo
