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 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
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.
>
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.
>
>
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
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
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
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
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
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
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 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 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 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 the
14 matches
Mail list logo
