Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

On Wed, May 30, 2018 at 2:53 PM Andrey Jivsov wrote: > The quoted text quoted is old. The need to upgrade TLS 1.2 code if I > support TLS 1.3 is new. No, I'm certain we had that discussion too. > I am curious about the scenarios when is this upgrade of TLS 1.2 to PSS > will take place? When

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

On 05/29/2018 06:17 PM, Martin Thomson wrote: > On Wed, May 30, 2018 at 7:20 AM Andrey Jivsov wrote: >> The issue here is that some hardware devices don't implement RSA CRT >> method with PSS, because they hard-wide RSA, legacy padding, and CRT >> method in one operation. RSA PSS can still be

[TLS] Publication has been requested for draft-ietf-tls-tls13-vectors-05

Sean Turner has requested publication of draft-ietf-tls-tls13-vectors-05 as Informational on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ ___ TLS mailing list

[TLS] I-D Action: draft-ietf-tls-tls13-vectors-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Example Handshake Traces for TLS 1.3 Author : Martin Thomson Filename:

Re: [TLS] WGLC for draft-ietf-tls-tls13-vectors

Ack, that makes it easier for me :) On Wed, May 30, 2018 at 11:22 AM Sean Turner wrote: > I think changing the Intended Status is all we’re looking. > spt > > On May 29, 2018, at 21:05, Martin Thomson wrote: > > > > The thought occurs, do you want a version with the final version number in >

Re: [TLS] WGLC for draft-ietf-tls-tls13-vectors

I think changing the Intended Status is all we’re looking. spt > On May 29, 2018, at 21:05, Martin Thomson wrote: > > The thought occurs, do you want a version with the final version number in > it? I see that TLS 1.3 is in front of the RFC editor right now, so I don't > anticipate any

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

On Wed, May 30, 2018 at 7:20 AM Andrey Jivsov wrote: > The issue here is that some hardware devices don't implement RSA CRT > method with PSS, because they hard-wide RSA, legacy padding, and CRT > method in one operation. RSA PSS can still be done, but only via a > general modexp operation, which

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

On Tue, May 29, 2018 at 4:21 PM, Salz, Rich wrote: >>There's a tradeoff between respecting the official allocation processes > and avoiding real-world breakage. I think we can all make our own > assessments > on the former, but for the latter, all the evidence we have so far is a >

Re: [TLS] WGLC for draft-ietf-tls-tls13-vectors

The thought occurs, do you want a version with the final version number in it? I see that TLS 1.3 is in front of the RFC editor right now, so I don't anticipate any changes and changing the examples creates a lot of churn (check out the diffs on this draft to get an idea). On Wed, May 30, 2018 at

[TLS] Protocol Action: 'Record Size Limit Extension for Transport Layer Security (TLS)' to Proposed Standard (draft-ietf-tls-record-limit-03.txt)

The IESG has approved the following document: - 'Record Size Limit Extension for Transport Layer Security (TLS)' (draft-ietf-tls-record-limit-03.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Benjamin Kaduk and

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

On 05/29/2018 01:58 PM, David Benjamin wrote: > On Tue, May 29, 2018 at 4:26 PM Andrey Jivsov > wrote: > > On 05/29/2018 01:07 PM, David Benjamin wrote: > > I'm not sure I follow this. So, in this scenario, you are the client. > > You wish to support TLS

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

On Tue, May 29, 2018 at 01:26:27PM -0700, Andrey Jivsov wrote: > On 05/29/2018 01:07 PM, David Benjamin wrote: > > I'm not sure I follow this. So, in this scenario, you are the client. > > You wish to support TLS 1.3, which requires supporting RSA-PSS in TLS > > 1.3, and this is fine. You are able

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

On Tue, May 29, 2018 at 4:26 PM Andrey Jivsov wrote: > On 05/29/2018 01:07 PM, David Benjamin wrote: > > I'm not sure I follow this. So, in this scenario, you are the client. > > You wish to support TLS 1.3, which requires supporting RSA-PSS in TLS > > 1.3, and this is fine. You are able to

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

>There's a tradeoff between respecting the official allocation processes and avoiding real-world breakage. I think we can all make our own assessments on the former, but for the latter, all the evidence we have so far is a claim from Peter that there exists software that

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

On Sun, May 27, 2018 at 09:56:30AM -0700, Eric Rescorla wrote: > Well, this is a bit premature because the document hasn't actually been > published, just approved. It's also not properly addressed -- regular allocations under the "specification required" policy go directly to IANA, whereas RFC

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

I'm not sure I follow this. So, in this scenario, you are the client. You wish to support TLS 1.3, which requires supporting RSA-PSS in TLS 1.3, and this is fine. You are able to verify RSA-PSS signatures from the server at TLS 1.3. At the same time, you still talk to some TLS 1.2 servers, so you

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

On Tue, May 29, 2018 at 12:35:20PM -0700, Andrey Jivsov wrote: > On 05/29/2018 12:13 PM, Benjamin Kaduk wrote: > > On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote: > >> Greetings. > >> > >> TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells that if a client > >> wants to

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

On 05/29/2018 12:13 PM, Benjamin Kaduk wrote: > On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote: >> Greetings. >> >> TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells that if a client >> wants to negotiate TLS 1.3, it must support an upgraded (and >> incompatible) version of

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote: > Greetings. > > TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells that if a client > wants to negotiate TLS 1.3, it must support an upgraded (and > incompatible) version of TLS 1.2, the one that changes RFC 5246 to allow >

[TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

Greetings. TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells that if a client wants to negotiate TLS 1.3, it must support an upgraded (and incompatible) version of TLS 1.2, the one that changes RFC 5246 to allow RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms. You might recall that the

Re: [TLS] New Version Notification for draft-wood-tls-ticketrequests-00.txt

On Tue, May 29, 2018 at 8:25 AM Sean Turner wrote: > > As Martin noted, this seems to be a pretty simple idea, but am curious if > others feel that way. > > Curious about the choice on the limit of 255 identifiers versus something > smaller. If the max ticket age is one week that could

Re: [TLS] New Version Notification for draft-wood-tls-ticketrequests-00.txt

As Martin noted, this seems to be a pretty simple idea, but am curious if others feel that way. Curious about the choice on the limit of 255 identifiers versus something smaller. If the max ticket age is one week that could theoretically be almost 5 years of tickets right? spt PS - Thanks

Re: [TLS] WGLC for draft-ietf-tls-tls13-vectors

> On May 8, 2018, at 20:30, Martin Thomson wrote: > > On Wed, May 9, 2018 at 2:56 AM Salz, Rich wrote: >> I dislike standard, and am fine with Informational or BCP. > > Agree regarding standard. > > I don't understand why BCP would be used for this. Besides, we probably > don't want to

Re: [TLS] TLS@IETF102: Agenda Topics

Just a reminder we’re going to submit our agenda request this week so get your agenda time request in soon. spt > On May 22, 2018, at 20:13, Sean Turner wrote: > > The TLS WG will be meeting @ IETF 102 in Montreal. To help the chairs get a > better handle on how much time we will need for

Re: [TLS] early code points assigned (was Re: early code point assignment for draft-ietf-tls-certificate-compression)

> On May 24, 2018, at 13:42, Adam Langley wrote: > > It's also been pointed out that 26 collides with the value in > https://tools.ietf.org/html/draft-ietf-quic-tls-12#section-9.2, authored by > Sean :) f2p (face to plam). spt ___ TLS mailing