On Sun, October 11, 2015 7:43 pm, Dave Garrett wrote:
> I'd like to get a sense of what the WG is willing to consider with regard
> to SHA-1, rather than only Viktor and myself discussing this. Basically, I
> see 3 options:
>
> Option 0: Do nothing new. SHA-1 is soft deprecated, but still a ful
On Tue, Nov 10, 2020 at 5:29 PM Victor Vasiliev wrote:
> On Mon, Nov 9, 2020 at 11:51 PM Martin Thomson wrote:
>
>> I've no objection to adopting this, though I will note that it is likely
>> of minimal use in the browser context due to the move to isolated storage
>> (which includes tickets).
On Sun, May 9, 2021 at 1:14 PM Mohit Sahni wrote:
> Hello TLS WG,
>
> RFC6962 only talks about support of CT to verify the server
> certificates, however while working on zero trust services that
> require MTLS for each connection, I realized that enabling CT for
> client certificates can make th
On Mon, May 10, 2021 at 9:43 AM Mohit Sahni wrote:
> Hi Ryan,
> Thanks for answering my question in a lot of detail. I asked this
> question in the context of a private PKI for client certificates. You
> can assume a scenario where the client certificates are issued to
> users/devices in an organ
On Mon, May 10, 2021 at 3:23 PM Mohit Sahni wrote:
> On Mon, May 10, 2021 at 8:41 AM Ryan Sleevi
> wrote:
> >
> >
> >
> > On Mon, May 10, 2021 at 9:43 AM Mohit Sahni
> wrote:
> >>
> >> Hi Ryan,
> >> Thanks for answering my question i
On Thu, May 20, 2021 at 1:56 AM Viktor Dukhovni
wrote:
> On Wed, May 19, 2021 at 10:29:43PM +, Salz, Rich wrote:
>
> > I support limiting it.
>
> I concur. These are not strings used between users to communicate in
> their native language. They are machine-to-machine protocol
> identifiers,
On Thu, May 20, 2021 at 1:03 PM Viktor Dukhovni
wrote:
> On Thu, May 20, 2021 at 04:45:23PM +, Andrei Popov wrote:
>
> > ALPN IDs are byte strings; the fact that some of them can be displayed
> > as ASCII character strings merely reflects the fact that those ALPN
> > IDs were chosen by humans
On Mon, Jul 19, 2021 at 11:02 AM Stephen Farrell
wrote:
> I don't find the reference to [FETCH] explains how that
> problem can be mitigated by browsers. (IIRC, adding that
> was the result of earlier discussion of this point?)
>
I'm not sure I'm parsing this correctly.
Are you saying that you
On Tue, Jul 20, 2021 at 10:19 AM Peter Gutmann
wrote:
> Hubert Kario writes:
>
> >I suggest you go back to the RFCs and check exactly what is needed for
> proper
> >handling of RSA-PSS Subject Public Key type in X.509. Specifically when
> the
> >"parameters" field is present.
>
> Looking at the
On Tue, Jul 20, 2021 at 12:17 PM Peter Gutmann
wrote:
> Is that purely to parse PSS in X.509, or for the overall PSS
> implementation?
>
The overall PSS implementation. Parsing PSS w/o an implementation is
sillypants.
Like most modern libraries, NSS is decoupled through various concerns. For
ex
On Thu, Jan 20, 2022 at 8:41 AM Hanno Böck wrote:
> Thus even if you think OCSP stapling and the whole process of revocation
> is useless, there are still good reasons for a server operator to enable
> stapling:
> 1. It avoids an extra connection for clients to the OCSP server, thus
> making clie
On Thu, Jan 20, 2022 at 10:31 PM Daniel Kahn Gillmor
wrote:
> This sounds a lot like a "SHOULD BUT WE KNOW YOU WONT". Why would a
> client deliberately fail a connection when the problem might be a flaw
> with an unrelated network service or a client-specific routing failure?
>
> I think we can
On Fri, Jan 21, 2022 at 9:52 AM Daniel Kahn Gillmor
wrote:
> I share your skepticism, but i'm still trying to salvage something
> useful -- for the purpose of defending against CA malfeasance -- from
> the mechanisms we have available.
>
Indeed, I think the goal is admirable, but I'm not sure th
On Fri, Jan 21, 2022 at 11:56 AM Viktor Dukhovni
wrote:
> > Do you think that DNSSEC should be soft-fail for CAA checks, or should
> > we urge the CAs to be more strict here? Perhaps that would be another
> > recommendation.
>
> CAA lookups must not softfail. This needs to be the case whether t
On Mon, Jan 24, 2022 at 11:18 AM Daniel Kahn Gillmor
wrote:
> So, arguably, the advantage of revocation checking via OCSP stapling
> over short-lived certificates today has to do with keeping CT logs a
> manageable size, not with any particular security gain in terms of
> revocation functionality
On Mon, Jan 31, 2022 at 12:08 PM Hubert Kario wrote:
>
> Browsers are the only software that use browser's implementation of
> certificate
> verification and revocation.
>
> And while they are significant users of TLS, they're definitely not the
> only important users of TLS.
In the context of
Hi Panos,
There was additionally some discussion during IETF 105 [1], which looked a
bit about the problem.
As a problem statement, it's definitely an interesting problem, and
certainly, one we need to start preparing to solve practically. I think one
very direct question is this: If we are confi
On Wed, Feb 16, 2022 at 2:41 PM Kampanakis, Panos wrote:
> Some responses below (sorry long email):
>
No worries, I think this invites some long responses, in part, because it's
complex.
> > how is that functionally different than simply saying "Intermediate 2"
> is the Trust Anchor, using the
On Sat, Feb 19, 2022 at 6:15 AM Ilari Liusvaara
wrote:
> > - Connection re-establishment affects the security and privacy
> > assumptions and should be captured. I am not sure the concern is
> > worse than the regular fingerprinting text already in the draft,
> > but point taken. We can improve t
On Fri, Feb 25, 2022 at 11:17 AM Ilari Liusvaara
wrote:
> I have hard time seeing how one could construct downgrade attack out of
> this, as it just requests extra data from server on fallback. For most
> other retry stuff, downgrade attack risk is obvious as less secure modes
> are introduced /
On Wed, Mar 14, 2018 at 6:52 PM, nalini elkins
wrote:
>
> All,
>
> In London now & back on email:
>
>
>- >> Nalini, why don't you (the consortium) define the standard, then?
>
>
>
> > Indeed, if a “TLS13-visibility” standard has to be defined, it would
> make sense for the consortium (rather
On Wed, Mar 14, 2018 at 7:17 PM, nalini elkins
wrote:
>
>>- > Nalini, why don't you (the consortium) define the standard, then?
>>
>>
>>
>> > Indeed, if a “TLS13-visibility” standard has to be defined, it would
>> make sense for the consortium (rather than the TLS WG) to define it.
>>
>>
>>
>
On Mon, Mar 19, 2018 at 10:20 AM, Colm MacCárthaigh
wrote:
> 2/ clients and browsers could easily consider such sessions insecure by
> default. This would mean that adopters would have to deploy configurations
> and mechanisms to enable this functionality, similar to - but beyond - how
> private
You will likely find
https://lists.w3.org/Archives/Public/ietf-http-wg/2018OctDec/0013.html
useful in explaining the process and purpose of errata, and what it means,
in practice, to update the document. This understanding will hopefully make
it clear why the errata was rejected.
On Thu, Oct 11, 2
On Mon, Oct 15, 2018 at 4:50 PM Viktor Dukhovni
wrote:
> Though I am generally an advocate for DANE, and have done much work to
> further its adoption, this is not a realistic proposal. DANE adoption
> in TLS will be incremental and will not be accomplished via a mandate.
>
> > On Oct 15, 2018,
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
On Mon, Dec 10, 2018 at 9:03 AM Daniel Kahn Gillmor
wrote:
> On Mon 2018-12-10 02:24:29 +, Salz, Rich wrote:
> >> * the status_request TLS extension doesn't provide a mechanism for
> >stapling OCSP for intermediate certs.
> >
> > Nobody does this. There's a handful of reasons, bu
On Tue, Dec 11, 2018 at 6:58 AM Daniel Kahn Gillmor
wrote:
> On Sun 2018-12-09 18:35:20 +0100, Kurt Roeckx wrote:
> > On Wed, Dec 05, 2018 at 07:07:30AM +0300, Daniel Kahn Gillmor wrote:
> >> One mitigating factor of the ETSI standard, i suppose, is that the
> >> CABForum's Baseline Requirements
On Thu, Dec 12, 2019 at 6:51 AM Hubert Kario wrote:
> If TLS 1.2 was looking insecure, I would be with you on this one. But given
> that TLS 1.2 can be configured to be as secure as TLS 1.3, I think
> introducing
> weak points to TLS 1.3, weak points we will have to live with for the next
> decad
On Wed, May 20, 2020 at 6:40 PM Russ Housley wrote:
> MINOR
>
> Section 1 also says:
>
>Because the above problems do not relate to the CA's inherent
>function of validating possession of names,
>
> The CA is responsible for confirming that the public key in the
> certificate corresp
On Thu, May 21, 2020 at 10:51 AM Russ Housley wrote:
>
>
> On May 21, 2020, at 10:12 AM, Ryan Sleevi wrote:
>
>
> On Wed, May 20, 2020 at 6:40 PM Russ Housley wrote:
>
>> MINOR
>>
>> Section 1 also says:
>>
>>Because the above problems d
On Mon, Mar 6, 2017 at 5:37 PM, Vlad Krasnov wrote:
> Don't know about neutral dictionary, but simply compressing Cloudflare
> cert using Google cert, gives an additional 6% using brotli -15.
>
> I would rather have a biased dictionary than none at all :)
>
> Cheers,
> Vlad
I can appreciate tha
On Thu, Mar 9, 2017 at 2:08 PM, Ilari Liusvaara
wrote:
> On name constraints, name-constraining a wildcard certificate (e.g.
> to "redact" data from CT) could be useful to avoid default-vhost
> attacks against HTTP servers (there are lots of servers that
> are misconfigured). Especially in HTTP/2
On Fri, Mar 10, 2017 at 7:33 AM Martin Rex wrote:
> CABrowser-Forum defines the rules which browsers implemenent on
> top of rfc2818 section 3.1 server endpoint identity checks
> of server certificates.
This is neither accurate nor correct. The CA/Browser Forum neither
describes nor dictates br
On Fri, Mar 24, 2017 at 1:23 AM, Viktor Dukhovni
wrote:
>
> > On Mar 24, 2017, at 1:08 AM, Martin Thomson
> wrote:
> >
> >> I've never seen
> >> a TLS server that has multiple chains to choose from for the same
> >> server identity.
>
> Both chains of course use SHA256.
>
> Sorry I meant to say
On Fri, Mar 24, 2017 at 1:10 PM, Martin Rex wrote:
> If Chrome really does AIA-fetching (*shudder*), how can it be disabled?
>
I can understand and appreciate your viewpoint, although we disagree. I'll
save the rest of the list from rehashing that discussion, since the topic
at hand was the ques
On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria wrote:
> Hello,
>
> How is Certificate Compression advantageous over tls cached-info extension?
> Only case I can think of is - when the certificate is being sent for the
> first time,
> it can be compressed. Since the client doesn't have a copy of
On Sat, Apr 22, 2017 at 5:42 PM, Kurt Roeckx wrote:
>
> So for OCSP of a subordinate CAs there doesn't seem to be any
> requirement for a nextUpdate.
>
Correct. This is part of the many asynchronicities related to CRLs and OCSP
in the BRs (another example:
https://cabforum.org/pipermail/public/20
On Sun, Apr 23, 2017 at 6:34 AM, Ilari Liusvaara
wrote:
>
> I meant if anyone has seen a OCSP response from "public" CA lately that
> lacks NextUpdate.
>
Why would it matter? Are you suggesting we determine what should be part of
TLS based on what CAs are doing? That's going to be sadness all aro
On Mon, Apr 24, 2017 at 3:58 AM, Nikos Mavrogiannopoulos
wrote:
>
> That's intentional.
And misguided. It violates the layering.
> Not every application is firefox or chrome and thus
> application writers cannot be expected to set sane defaults for OCSP
> validity time _when the nextUpdate fi
On Tue, Apr 25, 2017 at 5:50 AM, Nikos Mavrogiannopoulos
wrote:
>
> So you point is that as long as you don't use OCSP responses there is
> no interoperability issue. That's very interesting point. More
> interestingly you delegate that definition to an application profile.
> Could you refer to s
On Fri, Jun 2, 2017 at 6:31 AM, Toerless Eckert wrote:
> On Fri, Jun 02, 2017 at 01:16:01PM +0300, Richard Barnes wrote:
> > Operators trying to do this by inspecting TLS (and not decrypting) are
> > going to have a bad time anyway. With HTTP/2 connection coalescing, even
> > if they can see the
42 matches
Mail list logo
