Re: [TLS] Enforcing Protocol Invariants
>Hmm. TLS has gotten too complex. What makes you say that? Please be specific about what you think should be taken out. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)
Yes to what Viktor proposed. On 11/7/18, 11:27 PM, "TLS on behalf of Viktor Dukhovni" wrote: > On Nov 7, 2018, at 6:07 PM, Geoffrey Keating wrote: > > n general, though, what you're asking is "The CA signing this key has > instructed that I do not accept signatures made with it. Is it OK to > accept signatures made with it?" It's really hard to see how the > answer to that could generally be 'yes'. Thanks for everyone's input, this has been very helpful. The approach I'm inclined to take is as follows: 1. Always enforce key usage for your own certificate, ensuring key separation as provisioned at the time of key/certificate creation. This also maximizes opportunities for problems to be detected early and fixed. 2. Always enforce peer certificate key usage (separation) for ECDSA. ECDSA keys are more brittle when misused. 3. Enforce RSA peer certificate key usage when RSA key transport is locally disabled, allowing only (EC)DHE-RSA. This is always the case with TLS 1.3, but for TLS <= 1.2 subject to the enabled ciphers. The rationale for 3 is as follows: * The primary responsibility for doing key separation right falls on the key holder (as in 1). If that's always done correctly, the peer has nothing to second-guess. * If the key holder has no key separation, and makes key recovery possible through some sort of side-channel, then the attacker who recovers the key can always misuse that key via whichever key exchange is allowed by the certificate, when all are accepted by the client. Therefore, if the client supports both RSA key exchange and (EC)DHE-RSA, the attacker wins regardless of any effort by the client to enforce key usages. Which leaves the case where the client only accepts (EC)DHE-RSA (as with TLS 1.3 or TLS 1.2 with the RSA key exchange features disabled). In that case, if the attacker is able to compromise a server key constrained to "keyEncipherment", but cannot obtain a fraudulent certificate, then he'd have a certificate for just "keyEncipherment" which the client will refuse to honour for "digitalSignature". And so the client actually gets some measure of protection by doing keyUsage enforcement. This approach also has the advantage that legacy cases continue to (mis)behave like they always did, but the strictness rises to match the client's protocol preferences wether through use of TLS 1.3 (fresh start, fresh constraints) or by restricting TLS 1.2 ciphers in a way that makes keyUsage enforcement a practical counter-measure to at least some potential attacks. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt
Hiya, On 08/11/2018 17:21, Hubert Kario wrote: > what was the rationale for dropping the section about deprecating SHA-1 in > TLS > 1.2? I see nothing in minutes from IETF103. I asked during the presentation if the WG wanted to keep it or not, as it's clearly not quite the same as the rest of the document. The limited feedback in the room was that it'd be better to not include this here but to do it elsewhere, without identifying a specific document or activity that'd cover it. The logic was (IIUC) mostly down to keeping this draft more focused. I don't think it was a desire to keep using SHA-1. The draft minutes Rich sent do say: "Remove SHA-1 deprecation from this document." As we reckoned the above might be the case (as per the comment in the version before adoption), I went ahead and excised that bit for now. If the WG do prefer to keep it in, I'm fine with that, of course. Cheers, S. PS: I guess those are draft minutes and we should make sure this point is clear in 'em - I'll do that 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)
> On Nov 8, 2018, at 5:27 PM, Peter Gutmann wrote: > >> Always enforce peer certificate key usage (separation) for ECDSA. ECDSA keys >> are more brittle when misused. > > Since ECDSA can only do signing, isn't this a bit redundant? In other words > you can't really not enforce keyUsage for a signature-only algorithm. Well, ECDH keys (not really ECDSA) can do key agreement, and EC keys can be used for encryption with ECIES. In any case, it seems that other libraries are already requiring digitalSignature in keyUsage (when present) for ECDSA that don't yet do so for RSA, and I'm willing to go along with that. Trying to make a pragmatic choice... -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)
Blumenthal, Uri - 0553 - MITLL writes: >Always enforce peer certificate key usage (separation) for ECDSA. ECDSA keys >are more brittle when misused. Since ECDSA can only do signing, isn't this a bit redundant? In other words you can't really not enforce keyUsage for a signature-only algorithm. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Enforcing Protocol Invariants
On Thursday, November 8, 2018, Eric Rescorla wrote: > It's also worth noting that in practice, many sites are served on > multiple CDNs which do not share keying material. > > Encrypting common knowledge is cargo cult fetishism for cryptography. The files could be sent unencrypted, and protected using subresource integrity. If you are sharing the same data to multiple second parties to serve to a single third party, the value of encryption is less than zero. This could create a long drawn out argument which may prove that it is impossible to change anything about TLS as it has reached a point where too many people are doing too many things to it, that is outside any original or rational design. In any case, Eric, you inadvertently contradict yourself. The whole point of WebPKI is to certify trust, and has been an issue over the years. But CDNs act as a intermediary between the creator of the content and the end user. CDNs do not have as strict requirements as do CAs in terms of auditing, and have their own issues outside the scope of this conversation. Like I said, this could go on forever, I’m just making one point, you people have made a protocol does very little of what one should expect it should do, and the internet has evolved to be some sort of non functioning system, the best example of which would be that everyone has forgotten what URI standards are supposed to be about. In any case, TLS 1.3 won’t reach widespread adoption for another few years, and any subsequent protocol (independent of Google’s worldwide lab experiment) won’t be finalized for five years, and depending on how radical it is, won’t achieve mass adoption for four to fifteen years. By which point layer 2 protocols might allow for IPv6 jumbo packets to be used. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Enforcing Protocol Invariants
> On Nov 8, 2018, at 4:34 AM, Salz, Rich wrote: > > What makes you say that? Please be specific about what you think should be > taken out. One example area where the complexity is noticeably high: * Certificate selection metadata specificity seems to far exceed plausible diversity of choice on the peer end. Are there really clients or servers out there with so many different certificates to choose from that we need: a. CA name hints from client to server? b. OID filters in the certificate request from server to client? c. signature_algorithms_cert (TLS -> X.509 layer violation, I just ignore this one)? In TLS 1.2 the signature_algorithms extension needs to be combined with the certificate types list, and neither 5246 or 4492 provides a means for the client to decide which curves the server supports in the client certificate (addressed in TLS 1.3). TLS 1.2 has fixed-(EC)DH ciphersuites that should probably never have been defined, and for some unknown reason added MD5 as a valid signature algorithm hash, even though MD5 had already reached its use-by date... For simplicity, I am a fan of Mike Hamburg's STROBE (a protocol design framework, not a finished protocol): https://eprint.iacr.org/2017/003 of course one still needs to plug in some sort of PKI to get a complete system, but it robustly unifies many things that in TLS need to be built with one's bare hands. I do hope that STROBE is getting used somewhere, and not just languishing as a paper design. -- -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Enforcing Protocol Invariants
On Thu, Nov 8, 2018 at 6:31 PM Ryan Carboni wrote: > On Thursday, November 8, 2018, Eric Rescorla wrote: > >> It's also worth noting that in practice, many sites are served on >> multiple CDNs which do not share keying material. >> >> > Encrypting common knowledge is cargo cult fetishism for cryptography. The > files could be sent unencrypted, and protected using subresource integrity. > If you are sharing the same data to multiple second parties to serve to a > single third party, the value of encryption is less than zero. > I believe you are misunderstanding me. The issue is not about confidentiality of the records but about correctness. Consider the case where example.com which is hosted on two CDNs, X and Y. X and Y have different private keys (for the reasons you indicate) as well as different crypto configurations. The client does an A/ lookup for example.com and gets an A for X and then does a TXT lookup for example.com and gets the TXT for Y. This creates failures. We've spent quite a while working on this problem for ESNI and there aren't a lot of great answers right now. It seems like your proposal would suffer from the same issue. In any case, Eric, you inadvertently contradict yourself. The whole point > of WebPKI is to certify trust, and has been an issue over the years. But > CDNs act as a intermediary between the creator of the content and the end > user. CDNs do not have as strict requirements as do CAs in terms of > auditing, and have their own issues outside the scope of this conversation. > Well, I agree that this is out of scope, but the guarantees that the WebPKI claims to enforce (at least for DV) is effective control of the domain name, and a CDN acts as the origin server for a given domain and hence effectively controls it. I appreciate that many people don't like this, but it's essentially the only design that's consistent with having the CDN act for the origin, which is at present basically essential for good performance. In any case, TLS 1.3 won’t reach widespread adoption for another few years, > I don't know what you consider "widespread", but presently both Chrome and Firefox support TLS 1.3, and our data shows that about 5% of Firefox connections use TLS 1.3. Chrome's numbers are similar and the numbers from the server side perspective are higher (last time I checked, Facebook was reporting > 50% TLS 1.3). -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Enforcing Protocol Invariants
> On Nov 8, 2018, at 9:51 PM, Eric Rescorla wrote: > > I don't know what you consider "widespread", but presently both Chrome and > Firefox support TLS 1.3, and our data shows that about 5% of Firefox > connections use TLS 1.3. Chrome's numbers are similar and the numbers from > the server side perspective are higher (last time I checked, Facebook was > reporting > 50% TLS 1.3). Even my SMTP submission server is seeing its fair share of TLS 1.3 connections, from the iPhones of some of its users... The long tail of TLS 1.2 will persist for quite some time, but TLS 1.3 adoption ramp-up is happening. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Enforcing Protocol Invariants
I think I have implied that ClientHello is unneccesary to an extent, it can be replaced by a DNS TXT record. I think I implied that self-signed certificates are acceptable given the precedent of Let’s Encrypt and the use of DNSSEC (has there been evidence of DNS spoofing attacks against a CA?). I think my suggestion has the implication that protocol negotiation is unnecessary, although it can be kept. I think my suggestion would have automatic backwards compatibility. A TLS 1.2-only client (likely to be found in regulated sectors that requires middlebox inspection and decryption) would attempt to connect using port 443, while my proposed protocol would attempt to look up using DNS first to obtain DNS records relevant. By using separate ports for each new protocol, it maintains a greater level of cross-compatibility and allows for future development. These compounded extensions make the protocol less secure by making it harder to implement, particularly given the recent spate of attacks against unintuitively implemented state machines for key negotiation. The entire protocol should be removed and replaced by something far simpler.. Is this sufficiently specific? I hope in the future, the IETF TLS working group will reach out to middlebox designers to understand what they are exactly doing to TLS so that these things won’t be unexpected. I must also say that CBC isn’t bad, as long as the padding is considered to be part of the message to be authenticated. On Thursday, November 8, 2018, Salz, Rich wrote: > *>*Hmm. TLS has gotten too complex. > > > > What makes you say that? Please be specific about what you think should > be taken out. > > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Enforcing Protocol Invariants
Hello, пт, 9 нояб. 2018 г., 7:03 Ryan Carboni rya...@gmail.com: > I think I have implied that ClientHello is unneccesary to an extent, it > can be replaced by a DNS TXT record. > > I think I implied that self-signed certificates are acceptable given the > precedent of Let’s Encrypt and the use of DNSSEC (has there been evidence > of DNS spoofing attacks against a CA?). > Sure. At least this proof-of-concept one. https://blog.powerdns.com/2018/09/10/spoofing-dns-with-fragments/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] dropping draft-ietf-tls-dnssec-chain-extension as WG item
At IETF103, the WG considered the way forward for draft-ietf-tls-dnssec-chain-extension. Based on the attempts at discussion on the list and the sense in the room, the chairs believe that there is no longer interest in continuing work on draft-ietf-tls-dnssec-chain-extension as a WG document. The chairs will be dropping it as a WG item soon. To be clear, work on delivering DNSSEC records via a TLS extension can continue. The authors and/or others are free to progress this draft through other avenues or not to obtain IANA code points (see [0]). spt [0] https://datatracker.ietf.org/doc/rfc8447/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt
On Fri, Nov 9, 2018 at 2:20 AM Stephen Farrell wrote: > On 08/11/2018 17:21, Hubert Kario wrote: > > what was the rationale for dropping the section about deprecating SHA-1 in > > TLS > > 1.2? I see nothing in minutes from IETF103. > > I asked during the presentation if the WG wanted to > keep it or not, as it's clearly not quite the same > as the rest of the document. The limited feedback in > the room was that it'd be better to not include this > here but to do it elsewhere, [...] This is my understanding also, and I would support that plan. The question of versions is enough different that I think that it will progress on a different timescale. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Enforcing Protocol Invariants
Hi Ryan, Thanks for your comments. On Thu, Nov 8, 2018 at 12:44 AM Ryan Carboni wrote: > Hmm. TLS has gotten too complex. How does one create a new protocol? Maybe > we should ask Google. > > The SSHFP DNS record exists. DNSSEC exists. > > This might be a radical proposal, but maybe the certificate hash could be > placed in a DNS TXT record. > There's actually an RFC for this: https://tools.ietf.org/rfcmarkup?doc=6968. Unfortunately, it is not really a viable option for replacing the WebPKI for TLS for two reasons: 1. A nontrivial number of network elements will not correctly pass DNSSEC, and so attempting to use it will cause failures. 2. Essentially all clients and servers only support WebPKI authentication, so at least for existing applications (such as the Web), endpoints will need to support WebPKI for a very long time. There are some specific applications that could potentially use this method, but that's not going to work for most applications. It's also worth noting that in practice, many sites are served on multiple CDNs which do not share keying material. This is a real unsolved problem for Encrypted SNI and would also likely be a problem if the keys in question were endpoint keys. In another DNS TXT record, a list of supported protocols could be listed. > A DNS SRV record would define the port that one can use to connect to a > service, because the URL scheme died after .onion was recognized as a > domain and after chromium decided to that the presentation of sub domains > was unimportant. So no browser has to show which port it is connected to. > This is an orthogonal question to TLS, I believe. However, in general at least the Web community has decided that it's not excited about SRV. However, at least on the Web, the reason for the ubiquity of 443 isn't the inability to indicate the right port in the URL (which has a slot for this), but rather that other ports than 443 have much lower middlebox penetration rates. Although, to be radical, all anyone needs is RSA-2048, ephemeral DH-3072, > and SHAKE-128 as AEAD. > This is a fairly surprising proposed set of ciphers, given that the Internet seems to be rapidly moving towards elliptic curve. This proposal would certainly have very significantly worse computationsl performance than the mandatory TLS 1.3 ciphers. And maybe recommend that boot entropy could be obtained by using the timer > entropy daemon for one second (and which would in theory provide enough > entropy for perpetuity). > This also seems out of scope for TLS. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Enforcing Protocol Invariants
On 8 Nov 2018, at 08:44, Ryan Carboni wrote: > > This might be a radical proposal, but maybe the certificate hash could be > placed in a DNS TXT record. This is a bad idea. Overloading TXT records with special semantics rarely, if ever, has a happy ending. For instance application software would need to somehow work out which of the TXT records for some domain name was your hypothetical hash and which were SPF strings or whatever else has been dumped into TXT records. If you need to put this hash in the DNS, you might as well get a type code assigned for a specifc RR to do that. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Thanks to Benjamin Kaduk
> On Nov 9, 2018, at 00:21, Nico Williams wrote: > > On Thu, Nov 08, 2018 at 11:49:45AM -0500, Paul Wouters wrote: >> I wanted to thank Ben for the outreach he did in the last six months on >> the tls dnssec chain extension. It has been a difficult issue and I do >> wish the outcome was different. But during this time Ben put a lot of >> effort in trying to get the issues clarified and resolved both on the >> list of offlist. He repeatedly tried to engage more people of the WG >> and he made me feel that my opinions were not ignored. >> >> I am going to think a bit more on how we as IETF could have done better >> in this case, but I did want to share with the group that I think Ben >> made a real difference in trying to get this document out. >> >> Thanks Ben! > > I'd like to second this. I would like to thank Ben as well. He has done an exemplar job as AD. I would also like to thank my co-chairs Chris and Joe. Both Chris and Joe participated in a side meeting at IETF 102 as well as the virtual interim in September solely dedicated to this draft. > I'd also like to state a mea culpa. I did not understand the extent to > which this controversy would become a DoS on the WG. Perhaps it would > have been better to not get involved and then later publish a better > version of the extension. I can't be sure, but certainly avoiding that > large exchange of email would have been better. As co-chair, I feel like I have not done the greatest job during this effort, as I noted at the mic at IETF 103. I will repeat what I said at the mic - this was not my/our finest hour. The chairs are trying to learn from our mistakes. We are planning to have post mortem discussion with our AD as soon as reasonably possible to learn for our mistakes. If anyone wants to provide feedback please do so either directly to Ben (mailto:ka...@mit.edu), us (mailto:tls-cha...@ietf.org), the IETF chair (mailto:ch...@ietf.org), or the ombudsteam (see https://www.ietf.org/contact/ombudsteam/). spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] I-D Action: draft-housley-tls-tls13-cert-with-extern-psk-03.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 : TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key Author : Russ Housley Filename: draft-housley-tls-tls13-cert-with-extern-psk-03.txt Pages : 10 Date: 2018-11-08 Abstract: This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre- shared key (PSK). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-housley-tls-tls13-cert-with-extern-psk/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-housley-tls-tls13-cert-with-extern-psk-03 https://datatracker.ietf.org/doc/html/draft-housley-tls-tls13-cert-with-extern-psk-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-housley-tls-tls13-cert-with-extern-psk-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)
> On Nov 9, 2018, at 1:19 AM, Peter Gutmann wrote: > >> Well, ECDH keys (not really ECDSA) can do key agreement, and EC keys can be >> used for encryption with ECIES. > > Sure, in theory, but in practice I've never seen an (EC)DH cert used in TLS > (despite actively looking for one, Nor have I, and I rather think that introducing fixed-(EC)DH ciphers into TLS was a mistake, and glad to see them gone in TLS 1.3. > since it'd be a collectors item for the > cert collection [0]), and I doubt most implementations could even deal with > one if they saw one. Also, I don't think any TLS implementation, or > specification, does ECIES. So it's pretty much self-regulating... And yet I guess the possibility exists that some poor slob deploys a TLS server with an exotic EC key, that's supposed to be used for fixed-ECDH or CMS key envelopment. Does that risk key compromise given how fragile EC signatures when misused? I guess I am willing to risk failing a tiny fraction of handshakes in this case; and rumour has it I'd have some company, so the Haskell TLS library (where I'm helping the maintainers at the moment) won't stand out from the pack in being overly strict wrt. ECDSA keyUsage. The idea is to actually relax the rules a bit from what they've recently become, as based on the specs they're presently a bit too strict, and I am trying to dial them back to more practical choices. If you think that ECDSA keyUsage enforcement does more harm than good, I could reconsider, but I am inclined to be more cautious with EC than with RSA. -- -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)
Viktor Dukhovni writes: >Well, ECDH keys (not really ECDSA) can do key agreement, and EC keys can be >used for encryption with ECIES. Sure, in theory, but in practice I've never seen an (EC)DH cert used in TLS (despite actively looking for one, since it'd be a collectors item for the cert collection [0]), and I doubt most implementations could even deal with one if they saw one. Also, I don't think any TLS implementation, or specification, does ECIES. So it's pretty much self-regulating... Peter. [0] I know some test certs were generated about 20 years ago to demonstrate X9.42 use in S/MIME, but that's all I'm aware of. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Thanks to Benjamin Kaduk
I wanted to thank Ben for the outreach he did in the last six months on the tls dnssec chain extension. It has been a difficult issue and I do wish the outcome was different. But during this time Ben put a lot of effort in trying to get the issues clarified and resolved both on the list of offlist. He repeatedly tried to engage more people of the WG and he made me feel that my opinions were not ignored. I am going to think a bit more on how we as IETF could have done better in this case, but I did want to share with the group that I think Ben made a real difference in trying to get this document out. Thanks Ben! Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt
On Thursday, 8 November 2018 06:28:31 CET internet-dra...@ietf.org wrote: > 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 : Deprecating TLSv1.0 and TLSv1.1 > Authors : Kathleen Moriarty > Stephen Farrell > Filename: draft-ietf-tls-oldversions-deprecate-01.txt > Pages : 21 > Date: 2018-11-07 > > Abstract: >This document, if approved, formally deprecates Transport Layer >Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves >these documents to the historic state. These versions lack support >for current and recommended cipher suites, and various government and >industry profiles of applications using TLS now mandate avoiding >these old TLS versions. TLSv1.2 has been the recommended version for >IETF protocols since 2008, providing sufficient time to transition >away from older versions. Products having to support older versions >increase the attack surface unnecessarily and increase opportunities >for misconfigurations. Supporting these older versions also requires >additional effort for library and product maintenance. > >This document updates many RFCs that normatively refer to TLS1.0 or >TLS1.1 as described herein. This document also updates RFC 7525 and >hence is part of BCP195. what was the rationale for dropping the section about deprecating SHA-1 in TLS 1.2? I see nothing in minutes from IETF103. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 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
Re: [TLS] Thanks to Benjamin Kaduk
On Thu, Nov 08, 2018 at 11:49:45AM -0500, Paul Wouters wrote: > I wanted to thank Ben for the outreach he did in the last six months on > the tls dnssec chain extension. It has been a difficult issue and I do > wish the outcome was different. But during this time Ben put a lot of > effort in trying to get the issues clarified and resolved both on the > list of offlist. He repeatedly tried to engage more people of the WG > and he made me feel that my opinions were not ignored. > > I am going to think a bit more on how we as IETF could have done better > in this case, but I did want to share with the group that I think Ben > made a real difference in trying to get this document out. > > Thanks Ben! I'd like to second this. I'd also like to state a mea culpa. I did not understand the extent to which this controversy would become a DoS on the WG. Perhaps it would have been better to not get involved and then later publish a better version of the extension. I can't be sure, but certainly avoiding that large exchange of email would have been better. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
