[TLS] TLS1.3 status/expectations
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 Workshop sponsors. The workshop was constructive and helpful. There are a number of groups formally analyzing the protocol, some by hand and some with automated tools, they’ve already discovered issues that we’ve fixed [1]. The workshop made the following clear to us wrt TLS 1.3: o - Basically OK overall, but there was some sentiment that we should only do 0-RTT with PSK (see recent list discussion). o - Some researchers prefer the key schedule that is currently documented in the draft because it eases modular analysis of the protocol. Others prefer the simplified proposals in [2,3]. We are hoping to be able to do a WGLC sometime shortly after Buenos Aires (i.e., mid-April). Of course, this timeline is entirely dependent on the WG reaching consensus on the remaining issues. At this point we are looking at reducing change to the protocol. We are not looking to add any more features, removal of features and slight changes that improve the protocol are still on the table. Obviously, if we find any glaring issues we will fix them regardless. 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 weeks. J&S [0] https://www.internetsociety.org/events/ndss-symposium-2016/tls-13-ready-or-not-tron-workshop-programme [1] https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA [2] https://mailarchive.ietf.org/arch/msg/tls/uUbeVDQwJuZO_bYhOWJRvlNlNtg [3] https://mailarchive.ietf.org/arch/msg/tls/rgiTKwRb23T7iKjlkAQAt112ipY ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Removing the "hint" from the Session Ticket Lifetime 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 long to consider it valid, is a local issue and not necessarily a constant validity period over time. When memorizing time-of-creation, you always know exactly how old something is, no matter whether how many times the local validity period was changed in the meantime. -Martin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint
> 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 from the server. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Simplifying signature algorithm negotiation
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 SignatureAlgorithm/HashAlgorithm. In >>> TLS >>> > 1.2, signature algorithms are spread across the handshake. >>> [...] >>> > I propose we fold the negotiable parameters under one name. >>> [...] >>> > 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm >>> as >>> > they are. Introduce a new SignatureAlgorithm u16 type and negotiate >>> that >>> > instead. >>> >>> I previously proposed this here: >>> https://www.ietf.org/mail-archive/web/tls/current/msg18035.html >>> >>> ekr was against it, though it hasn't been discussed that throughly. >>> https://www.ietf.org/mail-archive/web/tls/current/msg18036.html >> >> >> Ah, thanks! I must have missed this discussion. Or perhaps I saw it and >> forgot. >> >> ekr, are you still against this sort of thing? I think the new CFRG >> signature algorithms tying decisions together is a good argument for why >> we'd want this. If we believe this trend is to continue (and I hope it >> does. Ed25519 is a nice and simple interface), trying to decompose it all >> seems poor. >> > > 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 :) > ekr, did you have confirmed or new thoughts on this change? >From elsewhere in the thread, I put together a draft PR if you wanted something to look at in that form. https://github.com/tlswg/tls13-spec/pull/404 It incorporated some of the suggestions in the thread (not mentioning the really legacy values, pairing NIST curves with hashes, etc.), but that's not the important part. The meat of the proposal is unifying signature algorithms under one number and a shared interface, which I think is a valuable simplification. David ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS1.3 status/expectations
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 weeks. I strongly support giving the research community enough time to analyze the protocol. Their methodology offers a different way of looking at security issues, and has already demonstrated its effectiveness at discovering protocol bugs. Cheers - Bill --- Bill Frantz| Concurrency is hard. 12 out | Periwinkle (408)356-8506 | 10 programmers get it wrong. | 16345 Englewood Ave www.pwpconsult.com |- Jeff Frantz | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint
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 > private data (whether PSK, session ticket key, or DH exponent) lets an > attacker retroactively decrypt data from all sessions established with the > PSK or Session Ticket. However, both mechanisms contain different language > around how the lifetimes of the resumption data is managed. > > After some discussion with Facebook and others, I'd like to suggest a > change in the wording of the draft to make the Session Ticket lifetime more > closely resemble the lifetime of the ServerConfiguration. IMHO the analogy between ServerConfiguration and SessionTicket is a flawed one. ServerConfiguration is created by the server unilaterally, at some time before the client connection and is not session-specific. The client has no implicit knowledge of the ServerConfiguration age. The situation is completely different with SessionTicket, which is created as a side-effect of the *current* handshake, and is always fresh when created. A SessionTicket lifetime hint that is a relative time is therefore quite sufficient and avoids clock synchronization and epoch time wrap-around problems. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] RSA-PSS in TLS 1.3
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 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 is a reasonable way forward or not. Thanks, J&S ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint
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 wanted to make is that relative times are practically enforceable by clients. For ticket_lifetime, which already is relative time, it is desirable to change them from an informative only behavior to being usable by clients, which Nick's pull request does. Enforcing relative time for things like tls ticket validity time has better security properties for certain use cases like key offloading. Nick's pull request limits the time clients can cache it to 7 days which is reasonable middle ground and clients can decide to delete the ticket earlier. I +1 the pull request. Subodh Iyengar From: TLS [tls-boun...@ietf.org] on behalf of Salz, Rich [rs...@akamai.com] Sent: Monday, February 29, 2016 9:15 AM To: m...@sap.com Cc: tls@ietf.org Subject: Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint > 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 from the server. ___ TLS mailing list TLS@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=qqjUPIB9UGopotanCAwZnp0-jzGVYglIQZJF_t3gzPA&s=-sv0ZsIso_1M3gqRtmLNdhvCr50uDuFVHhzZro2d4j8&e= ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
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 > with a few folks here is a proposal for moving forward. > > 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 is a reasonable way > forward or not. My instinct is to mandate PSS and let PKCS#1 rest in peace. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
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 is a reasonable > way forward or not. I recently already saw the message here asking for PKCS #1 1.5 compatibilty and was quite angry about it, but as there wasn't much discussion I thought this issue would go away. It seems it did not. RSA-PSS was specified as RFC 3447 in 2003. That was 13 years ago. Therefore we can conclude: * Whoever created that hardware implementation either did so more than 13 years ago (probably unlikely) or deliberately created hardware crypto with sub-standard algorithm support. * This can mean a couple of things: a) The hardware vendor knew about it and expected that they could prevent a move to RSA-PSS by lobbying standardization bodies (this is what they seem to do right now). In this case they deliberately want to weaken security and that behavior should not be encouraged. b) They didn't know about RFC 3447. That probably means they shouldn't develop crypto products at all. c) Something else? whatever the reason was, I can't find any reason I would find in any way acceptable. I think the TLS working group should not encourage such vendor behavior. Instead I think the opposite should happen: A clear statement that deploying sub-standard crypto technologies isn't acceptable and whoever does it has to expect breakage in the future. TLS suffered a lot in the past from misguided attempts to provide backwards compatiblity to weak algorithms. Most of the fancy named vulns in the past years can somehow be traced back to this problem. 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's not repeat the mistakes from the past. [1] https://blog.filippo.io/bleichenbacher-06-signature-forgery-in-python-rsa/ -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpFny99O0zsR.pgp Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
> 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's not repeat the mistakes from the past. I agree, we started 1.3 by removing old and deprecated stuff. We should not allow it now and risk weakening our work... B. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Simplifying signature algorithm negotiation
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 :)
> >
>
> ekr, did you have confirmed or new thoughts on this change?
>
> >From elsewhere in the thread, I put together a draft PR if you wanted
> something to look at in that form.
> https://github.com/tlswg/tls13-spec/pull/404
> It incorporated some of the suggestions in the thread (not mentioning the
> really legacy values, pairing NIST curves with hashes, etc.), but that's
> not the important part. The meat of the proposal is unifying signature
> algorithms under one number and a shared interface, which I think is a
> valuable simplification.
I think that changing the algorithm negotiation would make it both
simpler and more reliable.
Current TLS signature negotiation is not able to express real-world
constraints (matching of curve and hash[1]).
Also, I think the ranging should be as follows:
- 01xx: Avoid (would be insecure)
- 02xx: Avoid (would be insecure)
- 03xx: Avoid (who uses this hash?)
- 04xx: Schemes that sign SHA-256 hash
- 05xx: Schemes that sign SHA-384 hash
- 06xx: Schemes that sign SHA-512 hash
- xx00: Avoid ("Anonymous" looks like a mistake)
- xx01: Avoid (RSA-PKCS1-v1.5 is obsolete)
- xx02: Avoid (DSA is obsolete)
- xx03: ECDSA with new hashes
- Others: Other schemes
Which would allocate the new things as follows (from what I understand
RSA-PSS works):
- 0404: RSA-PSS/SHA256
- 0504: RSA-PSS/SHA384
- 0604: RSA-PSS/SHA512
- 0004: Ed25519
- 0005: Ed448
Valid for TLS 1.2 and up.
[1] This isn't about algorithm strength matching, it is about
interop.
-Ilari
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
> 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 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 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 is a reasonable way >> forward or not. > > My instinct is to mandate PSS and let PKCS#1 rest in peace. +1 As always, certificates are fine to be signed with PKCS#1, because we are not specifying certificate signatures, but in-protocol signatures *are* up to us. Yoav ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
> 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 period. >> Please respond on the list on whether you think this is a reasonable >> way forward or not. > > I recently already saw the message here asking for PKCS #1 1.5 > compatibilty and was quite angry about it, but as there wasn't much > discussion I thought this issue would go away. It seems it did not. > > RSA-PSS was specified as RFC 3447 in 2003. That was 13 years ago. > > Therefore we can conclude: > * Whoever created that hardware implementation either did so more than > 13 years ago (probably unlikely) or deliberately created hardware > crypto with sub-standard algorithm support. > * This can mean a couple of things: > a) The hardware vendor knew about it and expected that they could > prevent a move to RSA-PSS by lobbying standardization bodies (this is > what they seem to do right now). In this case they deliberately want to > weaken security and that behavior should not be encouraged. > b) They didn't know about RFC 3447. That probably means they shouldn't > develop crypto products at all. > c) Something else? Yeah, such as all of their customers are using PKCS#1 because that is what everybody uses in all current versions of TLS and several other protocols? Regardless, hardware vendors should rejoice. We’re giving their customers a good reason to buy new hardware. Yoav signature.asc Description: Message signed with OpenPGP using GPGMail ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
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 moving forward. > > 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 is a reasonable way > forward or not. > I agree with the others that TLS should use exclusively RSA-PSS (with all the parameters fixed according to the digest function used to digest the data) when RSA is used in the protocol. Implementations that can't support PSS in hardware can either implement it in software or use ECDSA or keep on using TLS 1.2. Cheers, Brian -- https://briansmith.org/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
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 proposal for moving forward. 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 is a reasonable way forward or not. I think that supporting PKCS1.5 fallback is the right thing to do for faster adoption of TLS 1.3, as specified above. PKCS #1.5 is allowed by https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-6.3.2.1 in X.509 certificates. X.509 certificate chain is a part of TLS handshake. The above proposal is about not restricting one type of signature, the end-entity signature, to PSS. This applies to client authentication, server authentication, or both. 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-friendly Internet. PKCS#1.5 is still fine for FIPS 140, Common Criteria, and in CA certificates in TLS 1.3. The WG can chose to remove PSS from one type of signature in TLS1.3. The affected implementations will need to cap negotiation at TLS 1.2. For more details: https://www.ietf.org/mail-archive/web/tls/current/msg19096.html ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
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
Re: [TLS] RSA-PSS in TLS 1.3
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 proposal for moving forward. > > 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 is a reasonable way > forward or not. I think that supporting PKCS1.5 fallback is the right thing to do for wider adoption of TLS 1.3, as specified above. PKCS #1.5 is allowed by https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-6.3.2.1 in X.509 certificates. X.509 certificate chain is a part of TLS handshake. The above proposal is about not restricting one type of signature, the end-entity signature, to PSS. This applies to client authentication, server authentication, or both. 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-friendly Internet. Even now PKCS#1.5 is allowed by FIPS 140, Common Criteria, and in CA certificates in TLS 1.3, and earlier TLS. The WG can chose to remove PSS from one type of signature in TLS1.3. This will result in affected implementations capping negotiation at TLS 1.2. There is no other fix in some cases. For more details: https://www.ietf.org/mail-archive/web/tls/current/msg19096.html (I posted earlier, but don't see the message. Sending this one more time, slightly edited) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
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 a "fallback" specified as an option. There's simply allowed and not allowed, with the former having no incentive to go away. Arguing to keep it now is equivalent to arguing to keep it forever. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
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-friendly Internet. Ok, look, I really would like to understand what you're trying to say here. What would such a warning look like? We have an RFC for PSS since 2003. We had several attacks showing the weakness of PKCS #1 1.5. Wasn't that warning enough? If not, how would such a warning look like? I'd really like to know, because we will have similar situations in the future and I'd like to avoid people lobbying in the background to continue supporting weak crypto. There will be some new TLS version some day and we will try to get better algorithms into it. So how do we warn you next time? -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpNpM6LT2ltE.pgp Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
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 https://tools.ietf.org/html/draft-ietf-tls-tls13-11. Why not ban PKCS #1.5 altogether from TLS 1.3? It will not only make TLS 1.3 more secure, but code simpler and footprint smaller. Besides, it's reasonable: TLS 1.2 already allows PSS in X.509 certs. You are arguing for the benefit of suddenly mandating a steel door on a grass hut. Joseph Salowey's proposal gives an option for the door, consistent with how TLS 1.2 does this for X.509 certs. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
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 won't ever support PKCS#1.5 for TLS 1.3, but I think that I would rather have users on 1.3 with PKCS#1.5 than have them stuck on 1.2. 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. Once we have information about usage for each signature scheme, I'll be happy to arrange for another "break the web" day. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
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. Once we have information about usage for each > signature scheme, I'll be happy to arrange for another "break the web" > day. 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. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
