Re: [TLS] Draft 18 review : Message splitting and interleaving
Hi list, I just proposed a new PR (#798) concerning the text in 5.1 (Record layer), following the discussion here (and not including the extra Handshake constraints). Best regards, olivier ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Maximum Fragment Length negotiation
Hi Thomas Your idea of defining a new similar extension is the only choice for us. Because as per existing max_fragment_length extension in RFC 6066, client should fail if it receives different value from server. And also your idea of making the new extension as mandatory for TLS1.3 is good, as it will be more useful for constraint server. Earlier in our team also we were discussing about defining new extension specially for constraint client and server. I suggest we should include the below points for new fragment length extension 1) As per RFC 6066, if 512 is negotiated then both entity should keep buffer of size 805 bytes (5 byte - record header, 512 bytes - data, 256 bytes - padding, 32 bytes - MAC). I think we should change this in our new fragment extension. If 512 is negotiated then both entity should not send any [D]TLS record of size more than that (includes record header and payload). Because the control overhead of 256 bytes padding and 32 bytes MAC are not applicable for recent AEAD algorithms. That too in AES_CCM there is no need of padding. 2) Currently least value supported by max_fragment_length is 512. I prefer we should add support for 256 and 128 also. If AES_CCM_8 is used, the control overhead on application record is 21 bytes (5 byte - record header, 8 byte - IV and 8 byte - MIC). If its DTLS record, overhead is 29 bytes. So if max fragment length is 128, we get 99 bytes for data. This is more than sufficient for a constraint protocol like CoAP. Note : Existing max_fragment_length extension cannot be extended to support new values like 128 and 256. 3) If a client sends both old and new extension, then priority should be given to new extension. Server MUST not send both the extension. I feel the current IoT world needs this kind of new extension. This is the time to do. Regards, Ashok Raja Ashok VK 华为技术有限公司 Huawei Technologies Co., Ltd. [Company_logo] Phone: Fax: Mobile: Email: 地址：深圳市龙岗区坂田华为基地 邮编：518129 Huawei Technologies Co., Ltd. Bantian, Longgang District,Shenzhen 518129, P.R.China http://www.huawei.com 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Thomas Pornin Sent: 30 November 2016 00:25 To: Fossati, Thomas (Nokia - GB) Cc: tls@ietf.org Subject: Re: [TLS] Maximum Fragment Length negotiation On Thu, Nov 24, 2016 at 09:10:00PM +, Fossati, Thomas (Nokia - GB) wrote: > I like your proposal, but I'm not convinced that overloading the > semantics of an already existing extension when used in combination > with a specific version of the protocol is necessarily the best > strategy. Besides, I'd like to be able to deploy a similar mechanism > in 1.2. Defining a new extension is certainly possible. However, it would then require deciding on the intended behaviour when both that new extension and the RFC 6066 extension are present. Tentatively, one could try this: - The new extension documents the maximum record length supported by whoever sends it. Encoding is as in RFC 6066: one byte of value x for a maximum record plaintext length of 2^(x+8) bytes). We extend that to the whole 1..8 range so that larger records may be used by implementations who can afford them and obtain some performance increase by doing so (actual maximum plaintext length will be slightly less than 65535 bytes becose the length header is 16-bit and there must be some room for the MAC). - If a client sends both the RFC 6066 extension and the new extension, and the server supports the new extension, then the RFC 6066 extension is ignored and only the new extension is used. A server MUST NOT send both extensions. - All implementations that support the extension MUST have the ability to apply a shorter size limit than their maximum limit (this is for _sending_ records). - The length sent by the server is the one that will be applied to subsequent records on the connection, in both directions. This applies to the whole connection, including subsequent handshakes (renegotiations), unless both client and server send the new extension again in a renegotiation (in which case the new length appplies). - If using TLS 1.3, then the following extra
Re: [TLS] Maximum Fragment Length negotiation
On Wednesday, 30 November 2016 11:20:01 CET Martin Thomson wrote: > On 30 November 2016 at 05:54, Thomas Pornin wrote: > > Any comments? > > I'm ambivalent on this generally: though I think that the general > notion is OK, I'm not sure about the details. > > In particular, you need to be clearer in your motivations: the point > is to ensure that little things (really little things) can talk to any > other TLS implementation. That seems inherently good, but it might > pay to dig into that some more: why is that good? because if they can't use TLS, they will create a bespoke protocol, and those have a tendency of being completely broken, on conceptual level, let alone implementation combine it with the fact that "trusted network" doesn't exist any more and you end up with solutions that are insecure with nobody using them knows they are insecure, especially in IoT space -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] PR#800: Clarify supported versions
https://github.com/tlswg/tls13-spec/pull/800 In Seoul we had rough consensus (or at least apathy) to leave the supported versions semantics alone but tighten up the language. The above PR does that. One point I notice we didn't discuss is whether we should require the server to check that ClientHello.legacy_version == 0303. NSS (and I believe BoringSSL) currently ignore it which i believe is the best reading of -18 and is what is in this PR. I think if we're going to change this we should just make it an error to have supported_versions and legacy_version != 0303. My preference would be to leave as-is, however. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR#800: Clarify supported versions
> I think if we're going to change this we should just make it an error to hav > supported_versions and legacy_version != 0303. My preference would be to > leave as-is, however. I think making it a MUST NOT is enough and gives the server freedom to do what it wants, including hunt down and forcibly upgrade the client software... ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] The TLS WG has placed draft-thomson-tls-tls13-vectors in state "Candidate for WG Adoption"
The TLS WG has placed draft-thomson-tls-tls13-vectors in state Candidate for WG Adoption (entered by Sean Turner) The document is available at https://datatracker.ietf.org/doc/draft-thomson-tls-tls13-vectors/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3
On 11/29/16 at 5:28 AM, rs...@akamai.com (Salz, Rich) wrote: Sure, here's my compressed cert. Ignore the fact that it's named "42.zip" -- see https://en.wikipedia.org/wiki/Zip_bomb The risks of uncompressing data sent from a counterparty who has not yet been authenticated, do not outweigh the gains. There is a long history of successful attacks on systems through zip decompressors. In general, adding complexity to a security system makes it harder to understand, easier to compromise and less secure. If the problem is that certificates are too big, fix that problem at the source. Cheers - Bill --- Bill Frantz| Privacy is dead, get over| Periwinkle (408)356-8506 | it. | 16345 Englewood Ave www.pwpconsult.com | - Scott McNealy | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Maximum Fragment Length negotiation
Asking ALL TLS implementations to change to accommodate these things is a pretty blunt instrument. I want to be sure that this is necessary. (FWIW, I think that this is a reasonable request, I would probably be OK with a smaller maximum by default even.) On 1 December 2016 at 00:22, Hubert Kario wrote: > On Wednesday, 30 November 2016 11:20:01 CET Martin Thomson wrote: >> On 30 November 2016 at 05:54, Thomas Pornin wrote: >> > Any comments? >> >> I'm ambivalent on this generally: though I think that the general >> notion is OK, I'm not sure about the details. >> >> In particular, you need to be clearer in your motivations: the point >> is to ensure that little things (really little things) can talk to any >> other TLS implementation. That seems inherently good, but it might >> pay to dig into that some more: why is that good? > > because if they can't use TLS, they will create a bespoke protocol, and those > have a tendency of being completely broken, on conceptual level, let alone > implementation > > combine it with the fact that "trusted network" doesn't exist any more and you > end up with solutions that are insecure with nobody using them knows they are > insecure, especially in IoT space > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Draft meeting minutes
I uploaded draft meeting minutes form the Seoul meeting to the proceedings ( https://www.ietf.org/proceedings/97/minutes/minutes-97-tls-00.txt). Thanks to Jim Schaad for taking minutes. Let me know if you have corrections. Cheers, Joe ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Confirming consensus: TLS1.3->TLS*
I took a very unofficial Twitter poll on this subject: https://twitter.com/grittygrease/status/80364408215424 Nick On Tue, Nov 29, 2016 at 5:47 AM Raja ashok wrote: > I feel we can go ahead with TLS 1.3. > > Or else TLS 3.4, because anyway we send 0x0304 on wire for TLS 1.3. > > > > I hope all other three options (TLS 2.0, TLS 2 and TLS 4) will make > confusion with SSL versions for end user. > > > -- > > Raja Ashok VK > 华为技术有限公司 Huawei Technologies Co., Ltd. > [image: image001.jpg] > > Phone: > Fax: > Mobile: > Email: > Huawei Technologies Co., Ltd. > Bangalore, India > > http://www.huawei.com > -- > > 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 > 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 > 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ > This e-mail and its attachments contain confidential information from > HUAWEI, which > is intended only for the person or entity whose address is listed above. > Any use of the > information contained herein in any way (including, but not limited to, > total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender by > phone or email immediately and delete it! > > > > > > -Original Message- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Sean Turner > Sent: 18 November 2016 07:43 > To: > Subject: [TLS] Confirming consensus: TLS1.3->TLS* > > > > At IETF 97, the chairs lead a discussion to resolve whether the WG should > rebrand TLS1.3 to something else. Slides can be found @ > https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf > . > > > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not > rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision > on the list so please let the list know your top choice between: > > > > - Leave it TLS 1.3 > > - Rebrand TLS 2.0 > > - Rebrand TLS 2 > > - Rebrand TLS 4 > > > > by 2 December 2016. > > > > Thanks, > > J&S > > ___ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Draft 18 certificate signature algorithm requirements
We've discussed this before, and the current state of the text is certainly much improved. I'd like to touch on one final point. The current text reads: Section 4.4.1.2 ( https://tools.ietf.org/html/draft-ietf-tls-tls13-18#page-56 ) All certificates provided by the server MUST be signed by a signature algorithm that appears in the "signature_algorithms" extension provided by the client, if they are able to provide such a chain (see Section 4.2.3). Certificates that are self-signed or certificates that are expected to be trust anchors are not validated as part of the chain and therefore MAY be signed with any algorithm. If the server cannot produce a certificate chain that is signed only via the indicated supported algorithms, then it SHOULD continue the handshake by sending the client a certificate chain of its choice that may include algorithms that are not known to be supported by the client. This fallback chain MAY use the deprecated SHA-1 hash algorithm only if the "signature_algorithms" extension provided by the client permits it. If the client cannot construct an acceptable chain using the provided certificates and decides to abort the handshake, then it MUST abort the handshake with an "unsupported_certificate" alert. The first and second paragraph are in conflict, unless the first paragraph's MUST is changed to a SHOULD, or a "MUST if at all possible", ... That is it fine to require the server to send a compatible rather than an incompatible certificate when it has at least one of each, but if the only choice is to fail, the second paragraph says that the server "SHOULD" send what it has, thus the first is not really a MUST as written. The only compromise in the direction of the first paragraph made in the second is that certificates (not self) signed with SHA1 MUST not be sent if the client did not offer to support it, even if that's the only certificate it has, and even if that SHA1 signature will never be used by the client (e.g. with a DANE-EE(3) TLSA record authenticating the server directly). The onus is correctly placed on the client (not on the server) to abort the connection, if the client's security requirements are not met by the server's certificate chain. So I'd like to see the text in the first paragraph changed to a SHOULD or worst-case a qualified "MUST whenever possible". I should also note that the second part of the first paragraph, which says: Certificates that are self-signed or certificates that are expected to be trust anchors are not validated as part of the chain and therefore MAY be signed with any algorithm. assumes that the server knows which of its certificates are trust anchors, but this is not something that the server can in general definitely know. All kinds of clients may use all kinds of methods to validate the server chain. So I think there is a final opportunity to polish the text by making it clear that the server SHOULD (whenever possible) send a certificate chain that the client is likely to be able to process, but otherwise proceed to the text in the second paragraph, which says (correctly) that it SHOULD otherwise send what it has, which may indeed prove sufficient to the client despite the apparent signature algorithm mismatch. On a related note, is there in the current draft anything that requires ECDSA certificates to bear ECDSA issuer signatures? Or has that finally been relaxed, allowing the transmission of EE ECDSA certs bearing RSA signatures (ideally the client also signals support for RSA signatures)? This would lift the restriction imposed by: https://tools.ietf.org/search/rfc4492#section-2.2 In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- capable public key and be signed with ECDSA. My impression is that the text in the last paragraph of 4.4.1.4: https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.4.1.4 Note that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for instance, an RSA key signed with an ECDSA key). seems to have the desired effect. Is that correct? If so, should the change from 4492 be stated more emphatically, making it clear that the older restriction no longer applies? -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Draft 18 certificate signature algorithm requirements
On Wed, Nov 30, 2016 at 9:50 PM, Viktor Dukhovni wrote: > > We've discussed this before, and the current state of the text is > certainly much improved. I'd like to touch on one final point. > > The current text reads: > >Section 4.4.1.2 ( https://tools.ietf.org/html/ > draft-ietf-tls-tls13-18#page-56 ) > >All certificates provided by the server MUST be signed by a signature >algorithm that appears in the "signature_algorithms" extension >provided by the client, if they are able to provide such a chain (see >Section 4.2.3). Certificates that are self-signed or certificates >that are expected to be trust anchors are not validated as part of >the chain and therefore MAY be signed with any algorithm. > >If the server cannot produce a certificate chain that is signed only >via the indicated supported algorithms, then it SHOULD continue the >handshake by sending the client a certificate chain of its choice >that may include algorithms that are not known to be supported by the >client. This fallback chain MAY use the deprecated SHA-1 hash >algorithm only if the "signature_algorithms" extension provided by >the client permits it. If the client cannot construct an acceptable >chain using the provided certificates and decides to abort the >handshake, then it MUST abort the handshake with an >"unsupported_certificate" alert. > > The first and second paragraph are in conflict, unless the first > paragraph's MUST is changed to a SHOULD, or a "MUST if at all > possible", ... That is it fine to require the server to send a > compatible rather than an incompatible certificate when it has at > least one of each, but if the only choice is to fail, the second > paragraph says that the server "SHOULD" send what it has, thus > the first is not really a MUST as written. > It's "MUST if... ". That's different from SHOULD unless because it means that the unless clause is that only reason for violating it, and then if that condition obtains it SHOULD do X but could presumably do other things. The onus is correctly placed on the client (not on the server) to > abort the connection, if the client's security requirements are not > met by the server's certificate chain. > > So I'd like to see the text in the first paragraph changed to a > SHOULD or worst-case a qualified "MUST whenever possible". > I don't see any difference between "MUST whenever possible" and the current language. On a related note, is there in the current draft anything that > requires ECDSA certificates to bear ECDSA issuer signatures? No. Nor has that been true since TLS 1.2. See: https://tools.ietf.org/search/rfc5246#section-7.4.2 If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension. Note that this implies that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for instance, an RSA key signed with a DSA key). This is a departure from TLS 1.1, which required that the algorithms be the same. Note that this also implies that the DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the algorithm used to sign the certificate. Fixed DH certificates MAY be signed with any hash/signature algorithm pair appearing in the extension. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are historical. > Or > has that finally been relaxed, allowing the transmission of EE > ECDSA certs bearing RSA signatures (ideally the client also signals > support for RSA signatures)? This would lift the restriction > imposed by: > >https://tools.ietf.org/search/rfc4492#section-2.2 > >In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- >capable public key and be signed with ECDSA. > > My impression is that the text in the last paragraph of 4.4.1.4: > >https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.4.1.4 > >Note that a certificate containing a key for one signature algorithm >MAY be signed using a different signature algorithm (for instance, an >RSA key signed with an ECDSA key). > > seems to have the desired effect. Is that correct? If so, should > the change from 4492 be stated more emphatically, making it clear > that the older restriction no longer applies? > Given that ECDHE_ECDSA is not even a concept in TLS 1.3, I don't see that this text is relevant. -Ekr > > -- > Viktor. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Confirming consensus: TLS1.3->TLS*
Nick Sullivan writes: >I took a very unofficial Twitter poll on this subject: >https://twitter.com/grittygrease/status/80364408215424 Given the lack of context for the question (an out-of-the-blue query to a random bunch of people on Twitter), I think the inevitable TLSy McTLSface (given as Crypty McCryptFace in one response) is kind of representative of the quality of responses... I actually completely agree with Timothy Jackson's recent posting: After 15 years, everyone but us still calls it SSL. We need to admit that we lost the marketing battle and plan for a world where everyone calls “TLS X” “SSL X”. Even “new” implementations call themselves “LibreSSL” and “BoringSSL” rather than “LibreTLS” or “BoringTLS”. Spurred by that, I've been watching out for any uses of $protocol- name that I come across in news, books, journals, blogs, whatever. It's pretty clear cut: What we call TLS, the rest of the world calls SSL. The only place where it was referred to specifically as TLS was in IETF WG postings and in conference papers. To the rest of the world, the protocol is SSL. So given that the world will know it as SSL , it had better have a number that makes explicit what precedence it takes, either 4 or 2017. Whatever it is, it needs to be something that can be ranked against "SSL" and "SSL 3" and be an obvious improvement. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Draft 18 certificate signature algorithm requirements
> On Nov 30, 2016, at 10:51 PM, Eric Rescorla wrote: > > > > On Wed, Nov 30, 2016 at 9:50 PM, Viktor Dukhovni > wrote: > > The current text reads: > >Section 4.4.1.2 ( > https://tools.ietf.org/html/draft-ietf-tls-tls13-18#page-56 ) > >All certificates provided by the server MUST be signed by a signature >algorithm that appears in the "signature_algorithms" extension >provided by the client, if they are able to provide such a chain (see >Section 4.2.3). Certificates that are self-signed or certificates >that are expected to be trust anchors are not validated as part of >the chain and therefore MAY be signed with any algorithm. > > [...] > > It's "MUST if... ". That's different from SHOULD unless because it > means that the unless clause is that only reason for violating it, and then > if that condition obtains it SHOULD do X but could presumably do > other things. Yes, I see. The stretch of text between the "MUST" and the "if" just happened to overflow my stack limit when I was rereading this today... Please pardon the short attention span. So all is well, unless there is merit it trying to word-smith the text to bring the "MUST" and "if" closer together The good new is that the intent is already just right. > I don't see any difference between "MUST whenever possible" > and the current language. Yes, fair enough... > On a related note, is there in the current draft anything that > requires ECDSA certificates to bear ECDSA issuer signatures? > > No. Nor has that been true since TLS 1.2. See: > https://tools.ietf.org/search/rfc5246#section-7.4.2 Great. Thanks. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Draft 18 certificate signature algorithm requirements
Viktor Dukhovni writes: >So I'd like to see the text in the first paragraph changed to a SHOULD or >worst-case a qualified "MUST whenever possible". Why is that whole thing even there in the first place? From the previous discussions where this came up, the pretty much universal consensus was that people were ignoring the requirement because it served no obvious purpose but broke interoperability. Unless you're a server operator that chooses to buy a whole bunch of $995 certs, one per algorithm, from a CA that allows you to choose which algorithm gets used for signing, the whole thing is completely inapplicable. You send whatever cert chain the CA gave you to the client, and it's up to them to decide whether they want to accept or reject. What would be lost by simply removing that entire block of text, since it's being ignored by implementers anyway? The solution is to remove it, not to fiddle with it until it becomes a no-op that matches what everyone is doing anyway. (This seems to be getting like PKIX where a mistake is never actually corrected, just watered down again and again over successive iterations of a spec until it's finally quietly dropped when no-one is looking). Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Confirming consensus: TLS1.3->TLS*
> On Nov 30, 2016, at 11:28 PM, Peter Gutmann wrote: > > I actually completely agree with Timothy Jackson's recent posting: > > After 15 years, everyone but us still calls it SSL. We need to > admit that we lost the marketing battle and plan for a world where > everyone calls “TLS X” “SSL X”. Even “new” implementations call > themselves “LibreSSL” and “BoringSSL” rather than “LibreTLS” or > “BoringTLS”. I'll drink to that! I also find it amusing that muttered under one's breath, with just a touch of voicing on the "s" sounds, SSL sounds rather like "azazel", which seems rather apt: https://en.wikipedia.org/wiki/Azazel -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Draft 18 certificate signature algorithm requirements
> On Nov 30, 2016, at 11:36 PM, Peter Gutmann wrote: > > Why is that whole thing even there in the first place? From the previous > discussions where this came up, the pretty much universal consensus was that > people were ignoring the requirement because it served no obvious purpose > but broke interoperability. Unless you're a server operator that chooses to > buy a whole bunch of $995 certs, one per algorithm, from a CA that allows > you to choose which algorithm gets used for signing, the whole thing is > completely inapplicable. You send whatever cert chain the CA gave you to > the client, and it's up to them to decide whether they want to accept or > reject. What would be lost by simply removing that entire block of text, > since it's being ignored by implementers anyway? The solution is to remove > it, not to fiddle with it until it becomes a no-op that matches what > everyone is doing anyway. I would agree, if indeed everyone were ignoring this. Sadly, that's not the case. In particular try to send to use a CAcert-issued client cert to send email with STARTTLS to outlook.com... So I wanted to see explicit text saying that the server SHOULD send what it has. Some folks here probably still think you and I (and perhaps ekr) are wrong, and that the server should drop the connection... This is not an invitation to reopen that wound. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
