On Tue, Mar 01, 2016 at 04:59:47AM +, Viktor Dukhovni wrote:
> It is much easier to mandate PSS in TLS 1.3 now, than to remove it
> later. Servers that can't do PSS will use TLS 1.2. This avoids
> a break-the-web day.
Sorry, ... than to remove *PKCS#1.5* later ...
--
Viktor.
On Tue, Mar 01, 2016 at 03:56:53PM +1100, Martin Thomson wrote:
> It seems like others are taking the position that we should say "MUST
> NOT use PKCS#1.5". I would love for that to be the case, but I want
> to separate decision path for that, preferably one that is somewhat
> under my control.
On 1 March 2016 at 04:32, Joseph Salowey wrote:
> We make RSA-PSS mandatory to implement (MUST implement instead of MUST
> offer). Clients can advertise support for PKCS-1.5 for backwards
> compatibility in the transition period.
>From my perspective, this is fine. I would like to say that we
On 02/29/2016 02:36 PM, Hanno Böck wrote:
We have an RFC for PSS since 2003.
We had several attacks showing the weakness of PKCS #1 1.5.
In the face of such danger, what's your opinion on PKCS #1.5 signatures
being perfectly fine in TLS 1.3 ? I refer to signatures in X.509 certs
in the latest
On Mon, 29 Feb 2016 12:35:57 -0800
Andrey Jivsov wrote:
> Without a generous advance warning about PKCS#1.5 removal by TLS 1.3,
> we have to deal with already deployed hardware. Had vendors and
> customers knew that TLS 1.3 will remove PKCS #1.5, we probably would
> have ended up with more PSS-fr
On Monday, February 29, 2016 03:35:57 pm Andrey Jivsov wrote:
> I think that supporting PKCS1.5 fallback is the right thing to do for
> wider adoption of TLS 1.3, as specified above.
I think it's long past the time where everyone has to acknowledge that within
protocols, there's no such thing as
On 02/29/2016 09:32 AM, Joseph Salowey wrote:
> We seem to have good consensus on moving to RSA-PSS and away from
> PKCS-1.5 in TLS 1.3. However, there is a problem that it may take some
> hardware implementations some time to move to RSA-PSS. After an off
> list discussion with a few folks here
I originally was okay with the proposal, but Brian made me think about the
timeline. And I liked Yoav’s sentiment ☺
RSA-PSS only for TLS 1.3
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On 02/29/2016 09:32 AM, Joseph Salowey wrote:
We seem to have good consensus on moving to RSA-PSS and away from
PKCS-1.5 in TLS 1.3. However, there is a problem that it may take
some hardware implementations some time to move to RSA-PSS. After an
off list discussion with a few folks here is a
Joseph Salowey wrote:
> We seem to have good consensus on moving to RSA-PSS and away from PKCS-1.5
> in TLS 1.3. However, there is a problem that it may take some hardware
> implementations some time to move to RSA-PSS. After an off list discussion
> with a few folks here is a proposal for movi
> On 29 Feb 2016, at 8:00 PM, Hanno Böck wrote:
>
> On Mon, 29 Feb 2016 09:32:04 -0800
> Joseph Salowey wrote:
>
>> We make RSA-PSS mandatory to implement (MUST implement instead of MUST
>> offer). Clients can advertise support for PKCS-1.5 for backwards
>> compatibility in the transition pe
> On 29 Feb 2016, at 7:39 PM, Viktor Dukhovni wrote:
>
> On Mon, Feb 29, 2016 at 09:32:04AM -0800, Joseph Salowey wrote:
>
>> We seem to have good consensus on moving to RSA-PSS and away from PKCS-1.5
>> in TLS 1.3. However, there is a problem that it may take some hardware
>> implementations
On Mon, Feb 29, 2016 at 05:16:44PM +, David Benjamin wrote:
> On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla wrote:
> >
> > I'm not sure. I agree that the CFRG thing seems to be a new development.
> > I'll
> > try to confirm my previous opinion or develop a new one over the weekend :)
> >
>
>
> PKCS #1 1.5 is a real problem. The last PKCS #1 1.5 signature related
> vuln that could've been prevented by using RSA-PSS was found 2 months
> ago [1]. The last one in a major implementation (BERserk) was in 2014.
>
> tl;dr: I don't think supporting PKCS #1 1.5 in TLS 1.3 is reasonable.
> Let'
On Mon, 29 Feb 2016 09:32:04 -0800
Joseph Salowey wrote:
> We make RSA-PSS mandatory to implement (MUST implement instead of MUST
> offer). Clients can advertise support for PKCS-1.5 for backwards
> compatibility in the transition period.
> Please respond on the list on whether you think this i
On Mon, Feb 29, 2016 at 09:32:04AM -0800, Joseph Salowey wrote:
> We seem to have good consensus on moving to RSA-PSS and away from PKCS-1.5
> in TLS 1.3. However, there is a problem that it may take some hardware
> implementations some time to move to RSA-PSS. After an off list discussion
> wit
There are 2 different issues being discussed here, lifetime of tickets and
configs.
It is probably better to revisit the discussion of whether or not to have
ServerConfig be relative or absolute after it is decided whether or not the DH
0-RTT handshake will still exist.
The general point I wan
We seem to have good consensus on moving to RSA-PSS and away from PKCS-1.5
in TLS 1.3. However, there is a problem that it may take some hardware
implementations some time to move to RSA-PSS. After an off list discussion
with a few folks here is a proposal for moving forward.
We make RSA-PSS man
On Tue, Feb 23, 2016 at 09:42:17AM -0800, Nick Sullivan wrote:
> Draft 11 currently supports both ServerConfiguration and PSK + Session
> Ticket for session resumption (0RTT or otherwise). Both mechanisms have the
> same properties in terms of forward secrecy: a compromise of the server's
> privat
On 2/29/16 at 6:45 AM, s...@sn3rd.com (Sean Turner) wrote:
One thing that was reinforced at TRON and we think the TLS WG
should be aware of is that the research community needs time to
do their analysis. With that in mind, the chairs are very
strongly leaning towards an extended WGLC of 6 wee
On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla wrote:
> On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin
> wrote:
>
>> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett
>> wrote:
>>
>>> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote:
>>> > This is a proposal for revising SignatureAlgorit
> What should be memorized/stored is absolute time-of-creation.
If the structure itself includes absolute times, then the memorization is
(trivially) simpler.
> How long to consider it valid, is a local issue and not necessarily a constant
> validity period over time.
True. Treat it as a hint
Salz, Rich wrote:
> Absolute lifetimes seem more robust; e.g., if you find one lying around,
> you don't have enough context to know if it's still good or not.
>
> We went from relative to absolute times in ACME for this reason.
What should be memorized/stored is absolute time-of-creation.
How l
At the TRON workshop [0], we (Joe and Sean) were asked to provide our views
about the status and timeline for TLS 1.3; we wanted to share the same
information with the WG.
Before that though, we want to thank the researchers for the time they put into
analyzing the protocol as well as the TRON
24 matches
Mail list logo
