Re: [Uta] UTS-46 / WHATWG

John C Klensin writes: >We had also, empirically and sadly, discovered that some registrars were not >as knowledgeable and/or careful as they had been expected to be when IDNA2003 >was approved. I'm shocked, shocked, to find that there are registrars who would act with anything less than

Re: [Uta] [TLS] Question regarding RFC 8446

Valery Smyslov writes: >I would add that if a (D)TLS profile for HL7 is written, UTA can be a natural >home for this draft. This seems to be like using an S-300 to take out a drone, to update the rabbits and cruise missiles analogy. The OP described the behaviour of a broken TLS implementation

Re: [Uta] [art] Artart last call review of draft-ietf-uta-rfc7525bis-09

Peter Saint-Andre writes: >Given that we already discuss these matters in Section 7.4, I don't see the >need for additional text. The issue that I pointed out is in section 4.1, "General Guidelines", while what you're referring to is buried in the security considerations right at the end.

Re: [Uta] [art] Artart last call review of draft-ietf-uta-rfc7525bis-09

Peter Saint-Andre writes: >Hi Cullen, having looked more closely at the text that's already in 7525bis, >I have a few questions inline... Me too, specifically in regard to the "DHE negotiation is broken" comment. The draft says: However, TLS 1.2 implementations SHOULD NOT negotiate

Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-10.txt

Uta on behalf of Yaron Sheffer writes: >This is a major new version, addressing (to the best of our knowledge) all >pending review >comments, Except the EtM one, see my post here on the 6th. Peter. ___ Uta mailing list Uta@ietf.org

Re: [Uta] [EXTERNAL] Re: [Last-Call] Secdir telechat review of draft-ietf-uta-rfc7525bis-09

Andrei Popov writes: >The TLS 1.3 adoption document you reference seems to be based solely on Web >browser data: This seems to be near-universal when TLS is discussed, see several previous examples of this on this list. Just as any new medical breakthrough announcement needs to have the word

Re: [Uta] [Last-Call] Secdir telechat review of draft-ietf-uta-rfc7525bis-09

Rob Sayre writes: >I don't understand your rationale here, though. If you've got existing systems with implemented, tested, and in-production TLS 1.2 stacks then the motivation to do a completely new TLS stack that does more or less the same thing as the old one but requires twice the code

Re: [Uta] [Last-Call] Secdir telechat review of draft-ietf-uta-rfc7525bis-09

Rob Sayre writes: >Also, in the realm of opinion rather than correctness: mandating TLS 1.2 >support is misguided. Every TLS implementation maintains divided codebases >for 1.2 vs 1.3. On desktop PCs and servers perhaps, but in embedded the very fact that you need two sets of codebases means

Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-08.txt

Peter Saint-Andre writes: >On 6/25/22 6:20 PM, Peter Gutmann wrote: >> Yaron Sheffer writes: >> >>> This revision addresses Ben's SecDir review, as well as several other >>> reviewers' comments. Thank you all! >> >> It doesn't have anything

Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-08.txt

Yaron Sheffer writes: >This revision addresses Ben's SecDir review, as well as several other >reviewers' comments. Thank you all! It doesn't have anything about EtM as per the recent discussion though... Peter. ___ Uta mailing list Uta@ietf.org

Re: [Uta] Extended Master Secret as a MUST in 7525bis

Ilari Liusvaara writes: >I think EtM is only MUST if blockmode (CBC) cipher is supported. And clients >SHOULD NOT send EtM if not sending any blockmode cipher suites (as it is not >possible to successfully negotiate EtM). Well, yeah, that was implied, EMS and EtM if it makes sense to do so.

Re: [Uta] Extended Master Secret as a MUST in 7525bis

Yaron Sheffer writes: >Ben Kaduk asked why we only added TLS 1.2 Extended Master Secret support as a >SHOULD, and we tend to agree (given widespread support of this feature) that >is needs to be a MUST [1]. We would appreciate the group’s input before we >make this change. This, alongside MUST

Re: [Uta] 7525bis: recommend RSASSA-PSS in TLS 1.2?

Peter Saint-Andre writes: >What is the sense of the WG about saying in 7525bis that support for RSASSA- >PSS should or should not be RECOMMENDED for TLS 1.2? Seems like a really bad idea. TLS, back to at least SSLv2 25 yeas ago, has always done PKCS#1v1.5 RSA, not PSS. I get that TLS 1.3

Re: [Uta] Adoption call for draft-sheffer-uta-rfc7525bis-00

Keith Moore writes: >It can be expensive to upgrade devices in some industrial applications. For the specific TLS implementation I was referring to in that post, upgrades have to be scheduled years in advance for each site, and for the next upgrade round, in 2030, will probably mean replacing

Re: [Uta] Adoption call for draft-sheffer-uta-rfc7525bis-00

Eric Rescorla writes: >if you are running a piece of hardware that cannot upgrade its TLS stack at >all, you quite likely have a number of serious unpatched vulnerabilities, and >should reconsider whether it is safe to have that hardware attached to the >Internet. Embedded non-upgradeable SCADA

Re: [Uta] SMTP Over TLS on Port 26 - Implicit TLS Proposal

John Levine writes: >10% is a pretty fat long tail. The people I know who run production mail >systems are much more concerned about receiving all of the real mail than >rejecting spam earlier. There's also a near-infinite amount of embedded and IoT that uses email to send out alerts of

Re: [Uta] MTA-STS with lots of domains

Viktor Dukhovni writes: >https://github.com/danefail/list :-( Woah, that's taking a DNSSEC mechanism back to the state of HOSTS.TXT from the 1980s. Once dane_fail_list.dat gets too big to be hand-edited, will someone create a global distributed database that can be queried for entries? You

Re: [Uta] SMTP Over TLS on Port 26 - Implicit TLS Proposal

Alice Wonder writes: >I'm a privacy zealot So how would deprecating opportunistic TLS help in that regard? Peter. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] SMTP Over TLS on Port 26 - Implicit TLS Proposal

Alice Wonder writes: >If it were up to me, an RFC would be published deprecating opportunistic TLS >for SMTP. Assuming you're actually serious, why? Peter. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal.

Ilari Liusvaara writes: >1) CN-IDs have long been deprecated. Right, but everyone uses the CN for the primary ID anyway, that's pretty much the universal usage for it. Deprecating this universal usage is an example of what someone on the PKIX list once called

Re: [Uta] back to smtp-sts-04

Viktor Dukhovni writes: >Here are the line counts for the "*.[ch]" files from what appears to be a >popular JSON parsing API for C: >[...] >That does not jive with relatively easy to parse... JSON is simple to parse in the same way that LDAP is lightweight, CIFS is

Re: [Uta] Threat model

Ralph Holz h...@net.in.tum.de writes: BTW, almost all protocols lack a definition of what they mean by authentication, too. Cas Cremers showed that IPSec authentication is broken for a number of definitions, although fortunately not for the intuitive one and the one it was probably designed for.

Re: [Uta] Opportunistic TLS and draft-ietf-uta-tls-bcp-04

Aaron Zauner a...@azet.org writes: And still the case with most ruby deployments: https://github.com/search?q=OpenSSL%3A%3ASSL%3A%3AVERIFY_NONEtype=Codeutf8=%E2%9C%93 That produces nearly 49K results for Ruby, more than an order of magnitude more than the next highest, Python. Is there any

Re: [Uta] POODLE

Salz, Rich rs...@akamai.com writes: It’s pretty simple: There are no longer any secure SSLv3 ciphers. I'm currently travelling and have only had time for a quick look at the Poodle doc, but it seems to require a combination of things, a client that automatically falls back to SSLv3, that runs