On Fri, Oct 22, 2021 at 04:50:05PM +, Salz, Rich wrote:
> > This has been my impression, too, but we want to check with the
> > list.
>
> OpenSSL has a comment "/* Only allow PSS for TLS 1.3 */" and it looks
> like the code (tls12_check_peer_sigalg() in ssl/t1_lib.c) enforces
> that.
So i
On Fri, Oct 22, 2021 at 05:55:41PM +, Salz, Rich wrote:
> >So if OpenSSL client connects to server that supports PSS but not
> >TLS 1.3, the connection will fail because the client vomits at the
> >server response?
>
> I *think* it will fail cleanly because it gets an ALERT message
On Mon, Oct 25, 2021 at 02:58:32PM +0300, Yaron Sheffer wrote:
> This is a relatively small rev from -02, with more clarity on key
> limits and mitigation of Triple Handshake (extended_master_secret).
>
> Our open issues are at https://github.com/yaronf/I-D/issues - fell
> free to comment or open
On Sun, Nov 14, 2021 at 08:27:25AM +, John Mattsson wrote:
>
> I promised to send some information to the list regarding security
> considerations for long connections. I think the (D)TLS 1.3 is
> lacking considerations on this as well so I made an issue for
> RFC8446bis.
>
> https://github.c
On Tue, Dec 07, 2021 at 03:59:50PM +0300, Valery Smyslov wrote:
> Hi,
>
> this message starts a Working Group Last Call for
> draft-ietf-uta-rfc7525bis-04:
> https://datatracker.ietf.org/doc/draft-ietf-uta-rfc7525bis/
>
> The WGLC will last for two weeks and will end on December the 21st.
> Plea
On Sun, Jun 19, 2022 at 09:16:48AM +, Peter Gutmann wrote:
> Yaron Sheffer writes:
>
> >Ben Kaduk asked why we only added TLS 1.2 Extended Master Secret
> >support as a SHOULD, and we tend to agree (given widespread support
> >of this feature) that is needs to be a MUST [1]. We would apprecia
On Wed, Sep 06, 2023 at 12:53:39PM -0400, Chris Lonvick wrote:
> Hi Viktor and all,
>
> I see your point.
>
> How about if the phrases "MUST NOT offer TLS_RSA_WITH_AES_128_CBC_SHA" in
> Sections 4 and 5 be changed to "SHOULD NOT offer..."?
>
> This seems to be more consistent with Section 4.2.1
On Mon, May 26, 2014 at 11:18:08AM +0200, Johannes Merkle wrote:
>
> 2. When re-using keys for ECDHE (which is the default behavior in some
> implementations, e.g. OpenSSL) or when using non-ephemeral ECDH, the
> validity of the received public DH-key should be checked to avoid non-
> group attack
On Mon, May 26, 2014 at 04:34:55PM +0200, Johannes Merkle wrote:
> I guess this is because X-only for Weierstrass is expensive,
> thus either uncompressed points are transmitted, in which
> case checking the validity of the point is cheap, or points
> are uncompressed, which implicitly verifies th
Here are some attacks that don't seem to be covered (maybe because
these aren't relevant):
- Not properly checking certificates.
(E.g. the "The Most Dangerous Code in the World"-paper)
Either completely omitting certificate validation, or using it in
completely insecure way (not checking hostnam
On Mon, Aug 04, 2014 at 09:50:35AM +0200, Leif Johansson wrote:
> On 2014-08-01 15:43, Ilari Liusvaara wrote:
> > Here are some attacks that don't seem to be covered (maybe because
> > these aren't relevant):
> >
> > - Not properly checking certificates.
On Thu, Aug 07, 2014 at 12:32:52PM +0300, Yaron Sheffer wrote:
>
> But I guess we jumped the gun by recommending Brainpool as the primary
> curve. I would like to remove this recommendation, and retain the NIST curve
> - which is all we have now. What do you think?
The problem with Brainpool is t
On Mon, Aug 18, 2014 at 10:10:51AM +0100, t.p. wrote:
> Is there an attack based on the TLS Heartbeat, and if so, should it be
> included?
I don't think so, unless the extension is badly misimplemented
("heartbleed" in OpenSSL). The extension itself has sufficient checks
(in fact, bit stricter tha
On Fri, Oct 24, 2014 at 05:21:03PM +0200, Leif Johansson wrote:
>
> Folks,
>
> This email starts a 2 week WGLC for draft-ietf-uta-tls-bcp-06. Please
> provide your comments no later than Friday the 7th of November.
Should there be anything about ensuring that trust anchors are
properly validat
On Wed, Nov 05, 2014 at 09:48:53PM -0800, Watson Ladd wrote:
>
> I want to make sure I understand the big picture of Token Binding and
> why it works the way it does: in particular, it replaces the TLS
> client authentication mechanism with a new one.
It does not replace TLS client authentication
On Tue, Aug 08, 2017 at 08:58:03AM -0400, Daniel Margolis wrote:
> Hi, Viktor,
>
> Thanks for the thorough writeup. A question about the "requirements" stated:
>
> 1. We need to provide a means for a domain to transition
> > from having an STS policy to not having an STS policy.
> > 2. The
On Tue, Aug 08, 2017 at 05:30:18PM +0300, Ilari Liusvaara wrote:
> On Tue, Aug 08, 2017 at 08:58:03AM -0400, Daniel Margolis wrote:
Also, reading the specification, there looks to be some issues with
the use of PKIX:
1) CN-IDs have long been deprecated. RFC 6125 is pretty clear that:
- If
On Thu, Oct 12, 2017 at 11:16:18AM +0100, Ivan Ristic wrote:
>
> Sorry, I should have made it more clear. I was using the conflict to give a
> supporting example for the conversation in the other thread.
>
> The custom MX hostname validation in MTA-STS conflicts with DANE, not
> because it's DANE
On Tue, Oct 24, 2017 at 12:10:57PM +0200, Daniel Margolis wrote:
>
> In short, I see neither strong arguments against SNI nor any particular
> reason to support it. I agree with Viktor that we can just require it (with
> Ivan's language) so as to move the spec forward and be future proof. That
> s
On Tue, Oct 24, 2017 at 12:09:07PM +, Daniel Margolis wrote:
> I think we talked about minimum TLS versions or acceptable cipher suites in
> the past and concluded they were more reasonable as a hypothetical v2
> feature.
>
> I share the fear that this would be an impediment to adoption and le
On Wed, Oct 25, 2017 at 08:06:30PM +0300, Yaron Sheffer wrote:
> On 24/10/17 15:44, Ilari Liusvaara wrote:
>
> If you think RFC7525 is lacking, feel free to propose a -bis version. I'm
> not being snarky: things might have changed in the 2 1/2 years since the
> document was pu
On Wed, Apr 18, 2018 at 03:54:14PM +, Daniel Margolis wrote:
>
> How is it counter-intuitive? TLS 1.3 requires SNI, no?
No, it does not.
- The server MAY require SNI.
- The client SHOULD send SNI.
- If the server requires SNI and client does not send one,
the server SHOULD send missing_ex
On Wed, Jan 09, 2019 at 01:28:29PM -0700, Grant Taylor wrote:
> On 01/09/2019 06:11 AM, John Levine wrote:
> > Yes, I know. The chances of verifying 80 names in a row without one of
> > them glitching does not seem high. I'd probably get rate limited first.
> > The usual LE rollover for a single
23 matches
Mail list logo
