Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting
Reminder. It’s tonight at 7:00 PM Japan time, 10:00 UTC. We won’t have Meetecho or audio streaming, but if a few remote people want to participate, we might be able to do something with Skype. Yoav > On 2 Nov 2015, at 10:28 AM, Yoav Nir wrote: > > Hi, all > > Since we’ve had quite a bit of bikeshedding about this on the list, we’d like > to gather and has it out face to face. > > So this Wednesday at 7:00 PM, right after the plenaries, we’ll meet at room > 421 to hash this out. > > Everyone’s invited, obviously. > > Yoav > > P.S. Someone’s asked me off-list whether there is any IPsecME document that > says not to trust SHA-1 in signatures, both AUTH payload and certificates, > the way the TLS 1.3 document may end up saying for TLS. I’m wondering if > RFC4307bis might be the place for this, in particular the signature in AUTH > payload. Just something to think about before we bikeshed.RFC4307bis > Bikeshedding Session. > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting
On Mon, November 2, 2015 8:58 pm, Yoav Nir wrote: > >> On 3 Nov 2015, at 1:33 PM, Tero Kivinen wrote: >> >> Yoav Nir writes: >>> There is 1 for âRSA Digital Signatureâ and you can encode any hash >>> function the you would like, but for ECDSA there is: >>> 9 - ECDSA with SHA-256 on the P-256 curve >>> 10 - ECDSA with SHA-384 on the P-384 curve >>> 11 - ECDSA with SHA-512 on the P-521 curve >> >> Also number 3 DSS Digital Signature uses a SHA-1 hash >> >>> So unless you go by RFC 7427, you canât mix and match. >> >> So everybody should move to use that :-) Yes, they should! Note that the repository uses a definite article (and we all know which curves the authors were referring to). So you can't do #9 with the brainpoolp256 curve, which is sub-optimal. > It could work for DSA. ECDSA with P-256 gets as input a 256-bit number. So > you couldnât fit the output of SHA-384 in there. It does work the other > way around (SHA-256 and P-384), but Iâm not sure whether that is any > more secure than SHA-256 with P-256. That's why X9.62 specifies using the left-most length of prime bits when the digest is larger than the length of the prime. It does work. Technically you can use ecdsa-with-SHA384 and "the P-256 curve", why you would want to is a different story. Odd fact: the WAPI protocol (Chinese wireless encryption and authentication protocol) uses SHA-256 with a special Chinese government-specified curve based on a 192-bit prime and doesn't follow X9.62. It uses the entire 256 bit digest to calculate the signature on the 192-bit curve. The 256-bit digest does "fit" since the math is all mod p. The result (r,s) is properly formed but s will be different from a standard ECDSA signature. Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting
> On 3 Nov 2015, at 1:33 PM, Tero Kivinen wrote: > > Yoav Nir writes: >> There is 1 for “RSA Digital Signature” and you can encode any hash >> function the you would like, but for ECDSA there is: >> 9 - ECDSA with SHA-256 on the P-256 curve >> 10 - ECDSA with SHA-384 on the P-384 curve >> 11 - ECDSA with SHA-512 on the P-521 curve > > Also number 3 DSS Digital Signature uses a SHA-1 hash > >> So unless you go by RFC 7427, you can’t mix and match. > > So everybody should move to use that :-) It could work for DSA. ECDSA with P-256 gets as input a 256-bit number. So you couldn’t fit the output of SHA-384 in there. It does work the other way around (SHA-256 and P-384), but I’m not sure whether that is any more secure than SHA-256 with P-256. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting
Yoav Nir writes: > There is 1 for “RSA Digital Signature” and you can encode any hash > function the you would like, but for ECDSA there is: > 9 - ECDSA with SHA-256 on the P-256 curve > 10 - ECDSA with SHA-384 on the P-384 curve > 11 - ECDSA with SHA-512 on the P-521 curve Also number 3 DSS Digital Signature uses a SHA-1 hash > So unless you go by RFC 7427, you can’t mix and match. So everybody should move to use that :-) -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting
> On 3 Nov 2015, at 10:48 AM, Dan Harkins wrote: > > > > On Sun, November 1, 2015 7:21 pm, Yoav Nir wrote: >> >>> On 2 Nov 2015, at 11:44 AM, Paul Wouters wrote: >>> >>> On Mon, 2 Nov 2015, Yoav Nir wrote: >>> P.S. Someoneâs asked me off-list whether there is any IPsecME document that says not to trust SHA-1 in signatures, both AUTH payload and certificates, the way the TLS 1.3 document may end up saying for TLS. Iâm wondering if RFC4307bis might be the place for this, in particular the signature in AUTH payload. Just something to think about before we bikeshed.RFC4307bis Bikeshedding Session. >>> >>> We should have text to clarify the difference of algorithm use in >>> IKE/IPsec and in AUTH processing. Initial thought is that AUTH >>> processing crypto restrictions don't beling in 4307bis. >> >> I think we do need some kind of statement along the lines: >> - With RSA signatures, use SHA-256 or better, not SHA-1 (BTW: 7296 says >> âSHOULD use SHA-1â and this is a document from only last yearâ¦) >> - Donât use DSS because that is only defined with SHA-1. >> - With ECDSA no need to specify because each curve comes with a hash > > Do you mean each _signature_ comes with a hash because you can > use different hash algorithms to sign with any given curve. X9.62 in > section 7.3, under Actions subsection e sub 1, even specifies what > to do if the hash function used in the signature produces a digest > that is greater than the length of the prime used in the curve > definition-- namely, take the left-most length of prime bits of the > digest to construct intermediate variable E. X9.62 allows it, but IKEv2 does not. See the IKEv2 Authentication Method table at http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12 There is 1 for “RSA Digital Signature” and you can encode any hash function the you would like, but for ECDSA there is: 9 - ECDSA with SHA-256 on the P-256 curve 10 - ECDSA with SHA-384 on the P-384 curve 11 - ECDSA with SHA-512 on the P-521 curve So unless you go by RFC 7427, you can’t mix and match. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting
On Sun, November 1, 2015 7:21 pm, Yoav Nir wrote: > >> On 2 Nov 2015, at 11:44 AM, Paul Wouters wrote: >> >> On Mon, 2 Nov 2015, Yoav Nir wrote: >> >>> P.S. Someoneâs asked me off-list whether there is any IPsecME >>> document that says not to trust SHA-1 in signatures, both AUTH payload >>> and certificates, the way the TLS 1.3 document may end up saying for >>> TLS. Iâm wondering if RFC4307bis might be the place for this, in >>> particular the signature in AUTH payload. Just something to think about >>> before we bikeshed.RFC4307bis Bikeshedding Session. >> >> We should have text to clarify the difference of algorithm use in >> IKE/IPsec and in AUTH processing. Initial thought is that AUTH >> processing crypto restrictions don't beling in 4307bis. > > I think we do need some kind of statement along the lines: > - With RSA signatures, use SHA-256 or better, not SHA-1 (BTW: 7296 says > âSHOULD use SHA-1â and this is a document from only last yearâ¦) > - Donât use DSS because that is only defined with SHA-1. > - With ECDSA no need to specify because each curve comes with a hash Do you mean each _signature_ comes with a hash because you can use different hash algorithms to sign with any given curve. X9.62 in section 7.3, under Actions subsection e sub 1, even specifies what to do if the hash function used in the signature produces a digest that is greater than the length of the prime used in the curve definition-- namely, take the left-most length of prime bits of the digest to construct intermediate variable E. Dan. > - PSK is fine because you are using a PRF. > - With anything else, donât use any hash weaker than SHA-256. > > If not here, where does this advice go? > > Yoav > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting
> On 2 Nov 2015, at 6:32 PM, Yaron Sheffer wrote: > > If not here, where does this advice go? I see your point. But for instance for X509 certificates, I really would like to not make any statement and point to whatever equivalent of PKIX documents there are on that. Does the TLS WG have any documents on crypto agility for PKIX? >>> >>> The TLS list currently has a thread about whether TLS 1.3 should prohibit >>> SHA-1 only in signatures or also in the certificate chain. >> >> https://mailarchive.ietf.org/arch/msg/tls/-1LxtUHZTQXvvMVsLR4jzp79q9E >>> >>> It’s not decided yet, but they *are* prohibiting SHA-1 in the protocol >>> (CertificateVerify message), and current spec prohibits server certificate >>> signed with SHA-1 (only EE certificate) when another certificate exists. >>> > > For TLS, the industry is moving faster than the WG on this. Chrome warnings > are causing people to migrate to all-SHA256 certificate chains soon. IKE > often works with custom certs and private CAs, so the IPsec community needs > to set its own standards. Chrome is both a TLS implementation and a PKIX relying party. The question there is not whether signing intermediate certificates with SHA-1 is good or bad. It’s definitely bad. These chains ought to be rejected. The only question is whether such advice belongs in the TLS spec or some PKIX document (tentatively named “SHA-1 die, die, die”) As for IKE, yes we often work with private CAs, but if those CAs sign certificates with SHA-1, it would make it as easy to forge as if they were public CAs. Issuance usually involves generating a certificate request and running an enrollment protocol, no matter how many layers of pretty purple GUI my employer hides this under. So if your private CA signs with SHA-1, it should be modified to sign with something better, just as it should have been modified to issue certificates with 2048-bit RSA rather than 1024-bit. Just like TLS, we can specify requirements on the certificates in an IPsecME spec, or we can rely on PKIX best practices. But what algorithm is used in the AUTH payload? That’s entirely up to us. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting
If not here, where does this advice go? I see your point. But for instance for X509 certificates, I really would like to not make any statement and point to whatever equivalent of PKIX documents there are on that. Does the TLS WG have any documents on crypto agility for PKIX? The TLS list currently has a thread about whether TLS 1.3 should prohibit SHA-1 only in signatures or also in the certificate chain. https://mailarchive.ietf.org/arch/msg/tls/-1LxtUHZTQXvvMVsLR4jzp79q9E It’s not decided yet, but they *are* prohibiting SHA-1 in the protocol (CertificateVerify message), and current spec prohibits server certificate signed with SHA-1 (only EE certificate) when another certificate exists. For TLS, the industry is moving faster than the WG on this. Chrome warnings are causing people to migrate to all-SHA256 certificate chains soon. IKE often works with custom certs and private CAs, so the IPsec community needs to set its own standards. Thanks, Yaron ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting
Forgot the link… > On 2 Nov 2015, at 12:38 PM, Yoav Nir wrote: > > >> On 2 Nov 2015, at 12:27 PM, Paul Wouters wrote: >> >> On Mon, 2 Nov 2015, Yoav Nir wrote: >> > P.S. Someone’s asked me off-list whether there is any IPsecME document > that says not to trust SHA-1 in signatures, both AUTH payload and > certificates, the way the TLS 1.3 document may end up saying for TLS. I’m > wondering if RFC4307bis might be the place for this, in particular the > signature in AUTH payload. Just something to think about before we > bikeshed.RFC4307bis Bikeshedding Session. We should have text to clarify the difference of algorithm use in IKE/IPsec and in AUTH processing. Initial thought is that AUTH processing crypto restrictions don't beling in 4307bis. >>> >>> I think we do need some kind of statement along the lines: >>> - With RSA signatures, use SHA-256 or better, not SHA-1 (BTW: 7296 says >>> “SHOULD use SHA-1” and this is a document from only last year…) >>> - Don’t use DSS because that is only defined with SHA-1. >>> - With ECDSA no need to specify because each curve comes with a hash >>> - PSK is fine because you are using a PRF. >>> - With anything else, don’t use any hash weaker than SHA-256. >>> >>> If not here, where does this advice go? >> >> I see your point. But for instance for X509 certificates, I really would >> like to not make any statement and point to whatever equivalent of PKIX >> documents there are on that. Does the TLS WG have any documents on >> crypto agility for PKIX? > > The TLS list currently has a thread about whether TLS 1.3 should prohibit > SHA-1 only in signatures or also in the certificate chain. https://mailarchive.ietf.org/arch/msg/tls/-1LxtUHZTQXvvMVsLR4jzp79q9E > > It’s not decided yet, but they *are* prohibiting SHA-1 in the protocol > (CertificateVerify message), and current spec prohibits server certificate > signed with SHA-1 (only EE certificate) when another certificate exists. > > Yoav > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting
> On 2 Nov 2015, at 12:27 PM, Paul Wouters wrote: > > On Mon, 2 Nov 2015, Yoav Nir wrote: > P.S. Someone’s asked me off-list whether there is any IPsecME document that says not to trust SHA-1 in signatures, both AUTH payload and certificates, the way the TLS 1.3 document may end up saying for TLS. I’m wondering if RFC4307bis might be the place for this, in particular the signature in AUTH payload. Just something to think about before we bikeshed.RFC4307bis Bikeshedding Session. >>> >>> We should have text to clarify the difference of algorithm use in >>> IKE/IPsec and in AUTH processing. Initial thought is that AUTH >>> processing crypto restrictions don't beling in 4307bis. >> >> I think we do need some kind of statement along the lines: >> - With RSA signatures, use SHA-256 or better, not SHA-1 (BTW: 7296 says >> “SHOULD use SHA-1” and this is a document from only last year…) >> - Don’t use DSS because that is only defined with SHA-1. >> - With ECDSA no need to specify because each curve comes with a hash >> - PSK is fine because you are using a PRF. >> - With anything else, don’t use any hash weaker than SHA-256. >> >> If not here, where does this advice go? > > I see your point. But for instance for X509 certificates, I really would > like to not make any statement and point to whatever equivalent of PKIX > documents there are on that. Does the TLS WG have any documents on > crypto agility for PKIX? The TLS list currently has a thread about whether TLS 1.3 should prohibit SHA-1 only in signatures or also in the certificate chain. It’s not decided yet, but they *are* prohibiting SHA-1 in the protocol (CertificateVerify message), and current spec prohibits server certificate signed with SHA-1 (only EE certificate) when another certificate exists. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting
On Mon, 2 Nov 2015, Yoav Nir wrote: P.S. Someone’s asked me off-list whether there is any IPsecME document that says not to trust SHA-1 in signatures, both AUTH payload and certificates, the way the TLS 1.3 document may end up saying for TLS. I’m wondering if RFC4307bis might be the place for this, in particular the signature in AUTH payload. Just something to think about before we bikeshed.RFC4307bis Bikeshedding Session. We should have text to clarify the difference of algorithm use in IKE/IPsec and in AUTH processing. Initial thought is that AUTH processing crypto restrictions don't beling in 4307bis. I think we do need some kind of statement along the lines: - With RSA signatures, use SHA-256 or better, not SHA-1 (BTW: 7296 says “SHOULD use SHA-1” and this is a document from only last year…) - Don’t use DSS because that is only defined with SHA-1. - With ECDSA no need to specify because each curve comes with a hash - PSK is fine because you are using a PRF. - With anything else, don’t use any hash weaker than SHA-256. If not here, where does this advice go? I see your point. But for instance for X509 certificates, I really would like to not make any statement and point to whatever equivalent of PKIX documents there are on that. Does the TLS WG have any documents on crypto agility for PKIX? Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting
> On 2 Nov 2015, at 11:44 AM, Paul Wouters wrote: > > On Mon, 2 Nov 2015, Yoav Nir wrote: > >> P.S. Someone’s asked me off-list whether there is any IPsecME document that >> says not to trust SHA-1 in signatures, both AUTH payload and certificates, >> the way the TLS 1.3 document may end up saying for TLS. I’m wondering if >> RFC4307bis might be the place for this, in particular the signature in AUTH >> payload. Just something to think about before we bikeshed.RFC4307bis >> Bikeshedding Session. > > We should have text to clarify the difference of algorithm use in > IKE/IPsec and in AUTH processing. Initial thought is that AUTH > processing crypto restrictions don't beling in 4307bis. I think we do need some kind of statement along the lines: - With RSA signatures, use SHA-256 or better, not SHA-1 (BTW: 7296 says “SHOULD use SHA-1” and this is a document from only last year…) - Don’t use DSS because that is only defined with SHA-1. - With ECDSA no need to specify because each curve comes with a hash - PSK is fine because you are using a PRF. - With anything else, don’t use any hash weaker than SHA-256. If not here, where does this advice go? Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting
On Mon, 2 Nov 2015, Yoav Nir wrote: P.S. Someone’s asked me off-list whether there is any IPsecME document that says not to trust SHA-1 in signatures, both AUTH payload and certificates, the way the TLS 1.3 document may end up saying for TLS. I’m wondering if RFC4307bis might be the place for this, in particular the signature in AUTH payload. Just something to think about before we bikeshed.RFC4307bis Bikeshedding Session. We should have text to clarify the difference of algorithm use in IKE/IPsec and in AUTH processing. Initial thought is that AUTH processing crypto restrictions don't beling in 4307bis. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting
Hi, all Since we’ve had quite a bit of bikeshedding about this on the list, we’d like to gather and has it out face to face. So this Wednesday at 7:00 PM, right after the plenaries, we’ll meet at room 421 to hash this out. Everyone’s invited, obviously. Yoav P.S. Someone’s asked me off-list whether there is any IPsecME document that says not to trust SHA-1 in signatures, both AUTH payload and certificates, the way the TLS 1.3 document may end up saying for TLS. I’m wondering if RFC4307bis might be the place for this, in particular the signature in AUTH payload. Just something to think about before we bikeshed.RFC4307bis Bikeshedding Session. BEGIN:VCALENDAR VERSION:2.0 PRODID:-//www.marudot.com//iCal Event Maker X-WR-CALNAME:RFC4307 Bikeshedding Session CALSCALE:GREGORIAN BEGIN:VTIMEZONE TZID:Asia/Tokyo TZURL:http://tzurl.org/zoneinfo-outlook/Asia/Tokyo X-LIC-LOCATION:Asia/Tokyo BEGIN:STANDARD TZOFFSETFROM:+0900 TZOFFSETTO:+0900 TZNAME:JST DTSTART:19700101T00 END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20151102T012630Z UID:20151102t012630z-928189...@marudot.com DTSTART;TZID="Asia/Tokyo":20151104T19 DTEND;TZID="Asia/Tokyo":20151104T21 SUMMARY:RFC 4307bis Bikeshedding Session DESCRIPTION:Discuss the algorithms and their level of requirement LOCATION:Room 421 BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:RFC 4307bis Bikeshedding Session TRIGGER:-PT15M END:VALARM END:VEVENT END:VCALENDAR___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
