[TLS] Re: draft-ietf-tls-key-share-prediction next steps

[Loganaden Velvindron]

On Wed, 11 Sept 2024 at 01:40, David Benjamin  wrote:
>
> Hi all,
>
> Now that we're working through the Kyber to ML-KEM transition, TLS 1.3's 
> awkwardness around key share prediction is becoming starkly visible. (It is 
> difficult for clients to efficiently offer both Kyber and ML-KEM, but a hard 
> transition loses PQ coverage for some clients. Kyber was a draft standard, 
> just deployed by early adopters, so while not ideal, I think the hard 
> transition is not the end of the world. ML-KEM is expected to be durable, so 
> a coverage-interrupting transition to FancyNewKEM would be a problem.)
>

Can you detail a little bit more in terms of numbers ?
-Did you discover that handshakes are failing because of the larger
ClientHello ?
-Some web clients aren't auto-updating ?

> We adopted draft-ietf-tls-key-share-prediction in June to address this. There 
> hasn't been a whole lot to do on it since. I've cut a new draft, 
> draft-ietf-tls-key-share-prediction-01, with some very minor changes that 
> were queued up in GitHub. I'd like to sort out next steps and move forward.
>
> Beyond that, there are a couple of minor issues in the issue tracker. I don't 
> believe either of these need to block getting a codepoint.
> https://github.com/tlswg/tls-key-share-prediction/issues/4 - unless folks 
> think otherwise, I plan to just leave this alone and close this
> https://github.com/tlswg/tls-key-share-prediction/issues/7 - unless folks 
> think otherwise, I plan to just leave this alone and not require the receiver 
> to check
>
> Finally, there's the question of downgrade protection:
> https://github.com/tlswg/tls-key-share-prediction/issues/11
>
> For some background if folks have forgotten, the original key share 
> prediction draft included a ton of complexity to accommodate existing server 
> behavior that would preferentially pick groups out of key_share even if an 
> otherwise more preferred group was in supported_groups. Depending on what the 
> server was trying to do there, this could be perfectly fine (if the server 
> believes the groups are comparable in security) or a downgrade risk (if the 
> server actually believed they were in different security classes---PQ vs 
> classical---but implemented a key_share-first selection algorithm anyway). 
> Pre-adoption, my original draft took the position that it was ambiguous and 
> we cannot safely assume the server knew what it was doing. It designed a 
> scheme to clarify the semantics going forward and use codepoints to ratchet 
> in whether the server implemented the new semantics.
> https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html
>
> After WG discussion, I think we broadly concluded the semantics were actually 
> already present in RFC 8446, and it was not worth the trouble to second-guess 
> the servers here. That led to the much simpler draft, which simply discusses 
> why this is OK in security considerations:
> https://www.ietf.org/archive/id/draft-ietf-tls-key-share-prediction-01.html#name-security-considerations
>
> As I wrote that text, I unsurprisingly agree with and am fine with this 
> outcome. :-) But there was some chatter about it in the adoption thread (see 
> GitHub link), so I filed the issue so we continued to discuss it. I think 
> perhaps now is the time to discuss it, if we're going to. Do folks want to 
> discuss it? Are there alternate proposals, or should we just stay the course? 
> Unless we have an alternate proposal, I propose we just stay the course and 
> go with [what I understand the conclusion to be from] the previous WG 
> discussion.
>
> If there are no further significant changes that folks want to make, I would 
> like to propose we get a codepoint for this and unblock implementation. The 
> earlier this is ready, the more likely that we will be prepared by the time 
> the next KEM transition happens.
>

We should move forward with the draft.

> Thoughts?
>
> David
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]X25519 mti for tls 1.3 proposed pr

[Loganaden Velvindron]

Hi all,

There were some discussions on github. I would be interested to get
feedback on the mailing list regarding this pr ?

https://github.com/tlswg/tls13-spec/pull/1360

Kind regards,
Logan
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Loganaden Velvindron]

On Tue, 4 Jun 2024 at 09:22, John Mattsson
 wrote:
>
> D. J. Bernstein wrote:
>
> >Again, I understand that certificates haven't upgraded t allowing Ed25519 
> >yet;
>

>
>
> The WebPKI forbids EdDSA and my understanding is that TLS library support is 
> lacking [1], but otherwise I don't think there are any problems with using 
> EdDSA certificates [2] in general. Ericsson is planning to start using 
> EdDSA+PQC hybrids soon. For new systems I think X25519, EdDSA, and SHAKE are 
> superior to P-256, ECDSA, and SHA-2. For existing systems it does not make 
> much sense to update, especially as most systems need to move to PQC 
> signatures soon.
>
>
>
> [1] https://github.com/netty/netty/issues/10916
>
> [2] https://datatracker.ietf.org/doc/html/rfc8410
>
>
Thanks.
> Loganaden Velvindron wrote:
>
> >My personal view is that it's important to have at least one "independent" 
> >curve like X25519
>
>
>
> I am very positive to using X25519 as I think it has better properties than 
> P-256. I am strongly against the idea that TLS needs an "independent" curve. 
> I think the idea that P-256 is backdoored is conspiracy theory nonsense.
>
Hi John,

Who is claiming that P-256 has a backdoor ?


> I really like Filippo Valsorda’s challenge to recover the seeds. I think NSA 
> should take on the challenge and give the bounty to charity. They have the 
> capability to win and they should have an interest in increasing trust in the 
> P-curves.
>
> https://words.filippo.io/dispatches/seeds-bounty/
>
Thanks for sharing.


> Cheers,
>
> John Preuß Mattsson
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: [EXTERNAL] Re: Curve-popularity data?

[Loganaden Velvindron]

On Mon, Jun 3, 2024, 20:59 Andrei Popov  wrote:

> Correct; e.g., Microsoft Azure is one of these environments that require
> NIST curves. Some Azure services have exceptions allowing 25519, however
> generally 25519+MLKEM will not be acceptable for Azure services, for both
> regulatory and security reasons.
>
>
>

There are  companies from africa that swear by 25519.  They build products
that ship with those.

In this part of the world, companies (and people) aren't so focused on
compliance with NIST standards as north american companies are.


Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Eric Rescorla 
> *Sent:* Monday, June 3, 2024 9:31 AM
> *To:* David Adrian 
> *Cc:* Salz, Rich ; tls@ietf.org
> *Subject:* [EXTERNAL] [TLS]Re: Curve-popularity data?
>
>
>
> Indeed. I'd like to pull this back a bit to the question of what we
> specify/mandate.
>
>
>
> As I understand the situation, there are a number of environments that
> require P-256, so it seems like it would not be practical to just
> standardize/mandate X25519 + MLKEM if we want to get to 100% PQ algorithms.
>
>
>
> -Ekr
>
>
>
>
>
>
>
> On Mon, Jun 3, 2024 at 7:20 AM David Adrian  wrote:
>
> I don't really see why popularity of previous methods is relevant to
> picking what the necessarily new method will be is, but from the
> perspective of Chrome on Windows, across all ephemeral TCP TLS (1.2 and
> 1.3, excluding 1.2 RSA), the breakdown is roughly:
>
>
>
> 15% P256
>
> 3% P384
> 56% X25519
> 26% X25519+Kyber
>
>
>
> On Mon, Jun 3, 2024 at 10:05 AM Filippo Valsorda 
> wrote:
>
> 2024-06-03 15:34 GMT+02:00 Bas Westerbaan :
>
> More importantly, there are servers that will HRR to X25519 if presented a
> P-256 keyshare. (Eg. BoringSSL's default behaviour.) Unfortunately I don't
> have data at hand how often that happens.
>
>
>
> Are you saying that some of the 97.6% of servers that support P-256 still
> HRR to X25519 if presented a P-256 keyshare and a {P-256, X25519} supported
> groups list, and that's BoringSSL's default behavior? I find that very
> surprising and would be curious about the rationale.
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Loganaden Velvindron]

On Mon, 3 Jun 2024 at 01:03, Filippo Valsorda  wrote:
>
> I expect X25519 to be the most commonly selected (as opposed to supported) 
> TLS key exchange on the open Internet, due to browsers preferring it for its 
> marginal performance benefit. This is not a popularity contest though and 
> that's not the most useful metric for choosing the ECC component of a PQC 
> hybrid.
>
> The most important performance consideration in TLS is avoiding Hello Retry 
> Request round-trips due to the server supporting none of the client's key 
> shares. Moreover, clients want to reuse the ECC component of the hybrid key 
> share as a pure ECC key share (e.g. send X25519, X25519+ML-KEM-768 vs P-256, 
> X25519+ML-KEM-768 so that the X25519 key generation can be reused).
>
> Given those goals, the important metric is server support. We should indeed 
> collect data on what are the most supported key exchanges server-side, 
> probably weighted by website or implementation popularity. (I expect X25519 
> and P-256 to have nearly equivalent support, maybe with some FIPS-related 
> delta in favor of P-256.)
>
> I actually meant to bring this up, because as an implementer I also want to 
> avoid proliferation of hybrid options, but it would actually make my life 
> much easier if the one universal hybrid (and/or default client key share) was 
> P-256+ML-KEM-768.
>
> The WebPKI is overwhelmingly RSA and P-256. Ed25519 is simply not allowed by 
> the CA/B Baseline Requirements. This is not changing soon. That means I am on 
> the hook to carry an optimized and secure P-256 implementation no matter what.

Maybe it's time for WebPKI to have more flexibility. They are going to
have to make changes anyway. Might as well push forward for Ed25519 ?

>
> If most clients send X25519 and/or X25519+ML-KEM-768 key shares, then I am 
> also on the hook to carry an optimized and secure X25519 implementation. 
> That's double the work, double the opportunity for mistakes, double the 
> complexity, double the attack surface.
>
> If we standardize around P-256+ML-KEM-768 in TLS, then performance of X25519 
> becomes much less important, and I can carry a simpler less efficient (e.g. 
> without assembly) implementation for it, and focus my limited resources on 
> P-256.

My personal view is that it's important to have at least one
"independent" curve like X25519 in hybrid mode for TLS in addition to
the NIST approved curve, even
at the cost of a little bit of performance.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

Re: [TLS] Adoption Call for draft-davidben-tls-key-share-prediction

[Loganaden Velvindron]

I support adoption of the document.

On Sat, May 4, 2024, 02:10 David Benjamin  wrote:

> Unsurprisingly, I support adoption. :-)
>
> On Fri, May 3, 2024 at 6:05 PM Joseph Salowey  wrote:
>
>> This is a working group call for adoption
>> for draft-davidben-tls-key-share-prediction.  This document was presented
>> at IET 118 and has undergone some revision based on feedback since then.
>> The current draft is available here:
>> https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/.
>> Please read the document and indicate if and why you support or do not
>> support adoption as a TLS working group item. If you support adoption
>> please, state if you will help review and contribute text to the document.
>> Please respond to this call by May 20, 2024.
>>
>> Thanks,
>>
>> Joe, Deidre, and Sean
>> ___
>> 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

Re: [TLS] WG Adoption for TLS Trust Expressions

[Loganaden Velvindron]

On Tue, 30 Apr 2024 at 03:20, Dennis Jackson
 wrote:
>
> When this work was presented at IETF 118 in November, several participants 
> (including myself, Stephen Farrell and Nicola Tuveri) came to the mic to 
> highlight that this draft's mechanism comes with a serious potential for 
> abuse by governments (meeting minutes).
>
> Although the authors acknowledged the issue in the meeting, no changes have 
> been made since to either address the problem or document it as an accepted 
> risk. I think its critical one of the two happens before this document is 
> considered for adoption.
>
> Below is a brief recap of the unaddressed issue raised at 118 and some 
> thoughts on next steps:
>
> Some governments (including, but not limited to Russia, Kazakhstan, 
> Mauritius) have previously established national root CAs in order to enable 
> mass surveillance and censorship of their residents' web traffic. This 
> requires trying to force residents to install these root CAs or adopt locally 
> developed browsers which have them prepackaged. This is widely regarded as a 
> bad thing (RFC 7258).

In the case of Mauritius, It was a proposal. There was public debate
and the overwhelming majority of Mauritians rejected the proposal from
the ICTA in 2021.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Deprecating Static DH certificates in the obsolete key exchange document

[Loganaden Velvindron]

On Mon, 15 Apr 2024 at 22:14, Joseph Salowey  wrote:
>
> At IETF 119 we had discussion that static DH certificates lead to static key 
> exchange which is undesirable.  Although the current draft deprecates static 
> DH ciphersuites, it seems that RFC 5246 allows the client to provide a 
> certificate with a static DH keypair to provide static parameters in (EC)DHE 
> in TLS 1.2 (I don't know of any implementations that do this).
>
> Should the draft deprecate these ClientCertificateTypes and mark the entries 
> (rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh) as 'D' 
> discouraged?
>
> Please respond with any comments on this proposal by April 30,2024.
>

Yes.

> Thanks,
>
> Sean, Deirdre and Joe
> ___
> 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] -draft8447bis: rename Support Group Elliptic curve groups space

[Loganaden Velvindron]

Clarification: I agree on the need to rename the group space. However, I
don't support using only mlkem as a curve for tls. However, mlkem as a
hybrid makes sense.

On Thu, Mar 28, 2024, 20:28 Loganaden Velvindron 
wrote:

> Agreed.
>
> On Thu, Mar 28, 2024, 19:50 Salz, Rich 
> wrote:
>
>> > we should really replace the “Elliptic curve groups” note in the 0-255,
>> 512-65535 range row with something else. I am open to suggestions, but
>> would like to propose “unallocated”.
>>
>> Short and to the point; +1
>>
>> The only alternative I can see is constantly adding things, and
>> eventually we get to "curves and lattices and heffalumps oh me..."
>>
>>
>> ___
>> 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] -draft8447bis: rename Support Group Elliptic curve groups space

[Loganaden Velvindron]

Agreed.

On Thu, Mar 28, 2024, 19:50 Salz, Rich 
wrote:

> > we should really replace the “Elliptic curve groups” note in the 0-255,
> 512-65535 range row with something else. I am open to suggestions, but
> would like to propose “unallocated”.
>
> Short and to the point; +1
>
> The only alternative I can see is constantly adding things, and eventually
> we get to "curves and lattices and heffalumps oh me..."
>
>
> ___
> 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] [EXTERNAL] Re: Next steps for key share prediction

[Loganaden Velvindron]

Any change of getting this adopted by the WG ?

On Mon, 18 Mar 2024 at 15:47, David Benjamin  wrote:
>
> > …and now I'm coming around to the idea that we don't need to do anything 
> > special to account for the "wrong" server behavior. Since RFC8446 already 
> > explicitly said that clients are allowed to not predict their most 
> > preferred groups, we can already reasonably infer that such servers 
> > actively believe that all their groups are comparable in security.
>
> I've now updated the draft to do this.
> https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-01.html
>
> It is now considerably simpler and just contains the DNS mechanism, plus a 
> discussion in Security Considerations why this is OK.
>
> On Tue, Mar 12, 2024 at 10:04 AM Andrei Popov  
> wrote:
>>
>> …and now I'm coming around to the idea that we don't need to do anything 
>> special to account for the "wrong" server behavior. Since RFC8446 already 
>> explicitly said that clients are allowed to not predict their most preferred 
>> groups, we can already reasonably infer that such servers actively believe 
>> that all their groups are comparable in security.
>>
>> It makes sense for some services to prioritize RTT reduction; others may 
>> prioritize group strength. There are a lot of services out there 
>> prioritizing weaker groups for CPU savings (e.g., this is one of the reasons 
>> why Curve 25519 is so popular).
>>
>>
>>
>> I... question whether taking that position is wise, given the ongoing 
>> postquantum transition, but so it goes
>>
>> Servers will have to be updated and reconfigured for PQC/hybrid support, at 
>> which time they will likely apply a different policy.
>>
>>
>>
>> Hopefully your TLS server software, if it advertises pluggable cryptography 
>> with a PQ use case, and yet opted for a PQ-incompatible selection criteria, 
>> has clearly documented this so it isn't a surprise to you. ;-)
>>
>> Correct.
>>
>>
>>
>> Between all that, we probably can reasonably say that's the server 
>> operator's responsibility?
>>
>> Yes.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Andrei
>>
>>
>>
>> From: TLS  On Behalf Of David Benjamin
>> Sent: Friday, March 8, 2024 3:25 PM
>> To: Watson Ladd 
>> Cc:  
>> Subject: [EXTERNAL] Re: [TLS] Next steps for key share prediction
>>
>>
>>
>> On Thu, Mar 7, 2024 at 6:34 PM Watson Ladd  wrote:
>>
>> On Thu, Mar 7, 2024 at 2:56 PM David Benjamin  wrote:
>> >
>> > Hi all,
>> >
>> > With the excitement about, sometime in the far future, possibly 
>> > transitioning from a hybrid, or to a to-be-developed better PQ algorithm, 
>> > I thought it would be a good time to remind folks that, right now, we have 
>> > no way to effectively transition between PQ-sized KEMs at all.
>> >
>> > At IETF 118, we discussed draft-davidben-tls-key-share-prediction, which 
>> > aims to address this. For a refresher, here are some links:
>> > https://davidben.github.io/tls-key-share-prediction/draft-davidben-tls-key-share-prediction.html
>> > https://datatracker.ietf.org/meeting/118/materials/slides-118-tls-key-share-prediction-00
>> > (Apologies, I forgot to cut a draft-01 with some of the outstanding 
>> > changes in the GitHub, so the link above is probably better than draft-00.)
>> >
>> > If I recall, the outcome from IETF 118 was two-fold:
>> >
>> > First, we'd clarify in rfc8446bis that the "key_share first" selection 
>> > algorithm is not quite what you want. This was done in 
>> > https://github.com/tlswg/tls13-spec/pull/1331
>> >
>> > Second, there was some discussion over whether what's in the draft is the 
>> > best way to resolve a hypothetical future transition, or if there was 
>> > another formulation. I followed up with folks briefly offline afterwards, 
>> > but an alternative never came to fruition.
>> >
>> > Since we don't have another solution yet, I'd suggest we move forward with 
>> > what's in the draft as a starting point. (Or if this email inspires folks 
>> > to come up with a better solution, even better! :-D) In particular, 
>> > whatever the rfc8446bis guidance is, there are still TLS implementations 
>> > out there with the problematic selection algorithm. Concretely, OpenSSL's 
>> > selection algorithm is incompatible with this kind of transition. See 
>> > https://github.com/openssl/openssl/issues/22203
>>
>> Is that asking whether or not we want adoption? I want adoption.
>>
>>
>>
>> I suppose that would be the next step. :-) I think, last meeting, we were a 
>> little unclear what we wanted the document to be, so I was trying to take 
>> stock first. Though MT prompted me to ponder this a bit more in 
>> https://github.com/davidben/tls-key-share-prediction/issues/5, and now I'm 
>> coming around to the idea that we don't need to do anything special to 
>> account for the "wrong" server behavior. Since RFC8446 already explicitly 
>> said that clients are allowed to not predict their most preferred groups, we 
>> can already reasonably infer that such servers actively beli

Re: [TLS] ML-KEM key agreement for TLS 1.3

[Loganaden Velvindron]

On Wed, Mar 6, 2024, 06:16 Deirdre Connolly 
wrote:

> I have uploaded a preliminary version of ML-KEM for TLS 1.3
> 
> and have a more fleshed out
>  version to
> be uploaded when datatracker opens. It is a straightforward new
> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
> very similar style to -hybrid-design
> .
>
> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
> compatible) ready to go when users are ready to use them.
>

Are those people ready to fork chrome or Firefox for internal use ?



> Cheers,
> Deirdre
> ___
> 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] Working Group Last Call for ECH

[Loganaden Velvindron]

I also support seeing the document moving forward.

On Tue, Mar 12, 2024, 16:37 Salz, Rich 
wrote:

> I support advancing this document.
>
> ___
> 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] Adoption call for 'TLS 1.2 Feature Freeze'

[Loganaden Velvindron]

Peter,

I'm curious. Are those embedded devices or IoT type of appliances
where the firmware has a TLS
library that will never be updated ?


On Tue, 12 Dec 2023 at 05:30, Peter Gutmann  wrote:
>
> Rob Sayre  writes:
>
> >>Given that TLS 1.2 will be around for quite some time
> >Not clear.
>
> Absolutely clear.  I work with stuff with 20-30 year deployment and life
> cycles.  I'm fairly certain TLS 1.2 will still be around when the WebTLS world
> is debating the merits of TLS 1.64 vs. TLS 1.65.
>
> (This is also why the TLS-LTS draft was created, BTW).
>
> Peter.
>
>
> ___
> 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] Adoption call for 'TLS 1.2 Feature Freeze'

[Loganaden Velvindron]

I support adoption.

On Wed, Dec 6, 2023, 09:35 Deirdre Connolly 
wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This
> call is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.
>
> Thanks,
> Deirdre, Joe, and Sean
> ___
> 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] Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

[Loganaden Velvindron]

I support moving forward with this document.

On Wed, 25 Oct 2023 at 04:49, Andrei Popov
 wrote:
>
> Hi TLS,
>
>
>
> We would like to re-introduce 
> https://datatracker.ietf.org/doc/draft-davidben-tls13-pkcs1/
>
> (it’s intended for the TLS WG and the Standards track, despite what the 
> document says at the top; we’ll fix it as soon as the submission tool 
> reopens).
>
>
>
> In the course of TLS 1.3 deployment, it became apparent that a lot of 
> hardware cryptographic devices used to protect TLS client certificate private 
> keys cannot produce RSA-PSS signatures compatible with TLS.
>
> This draft would allow RSA-PKCS signatures in the client CertificateVerify 
> messages (and not in any other contexts), as a way to unblock TLS 1.3 
> deployments.
>
> This is an unfortunate situation, and work is being done with hardware 
> vendors to reduce the likelihood of similar issues in the future, but 
> existing devices tend to stay around for years.
>
>
>
> Comments/suggestions are welcome,
>
>
>
> Cheers,
>
>
>
> Andrei
>
> ___
> 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] What is the TLS WG plan for quantum-resistant algorithms?

[Loganaden Velvindron]

I support moving forward with hybrids as a proactively safe deployment
option. I think that supporting
only Kyber for KEX  is not enough. It would make sense to have more options.

Google uses NTRU HRSS internally:
https://cloud.google.com/blog/products/identity-security/why-google-now-uses-post-quantum-cryptography-for-internal-comms

If Google decides to use this externally, how easy would it be to get
a codepoint for TLS ?


On Tue, 7 Nov 2023 at 12:30, Scott Fluhrer (sfluhrer)
 wrote:
>
> The problem with the argument “X trusts Kyber, so we don’t need hybrid” 
> (where X can be “NIST” or “the speaker”) is that trust, like beauty, is in 
> the eye of the beholder.  Just because NIST (or any other third party) is 
> comfortable with just using Kyber (or Dilithium) does not mean that everyone 
> does.
>
>
>
> As long as there are a number of users that don’t quite trust fairly new 
> algorithms, there will be a valid demand for using those new algorithms with 
> older ones (which aren’t postquantum, but we are moderately confident that 
> are resistant to conventional cryptanalysis).
>
>
>
> From: TLS  On Behalf Of Watson Ladd
> Sent: Monday, November 6, 2023 2:44 PM
> To: Kris Kwiatkowski 
> Cc: Bas Westerbaan ; TLS List 
> 
> Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?
>
>
>
> Why do we need FIPS hybrids? The argument for hybrids is that we don't trust 
> the code/algorithms that's new. FIPS certification supposedly removes that 
> concern so can just use the approved PQ implementation.
>
>
>
> ___
> 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] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

[Loganaden Velvindron]

I support adoption of this document.

On Tue, 26 Sept 2023 at 20:46, David Benjamin  wrote:
>
> Hi all,
>
> A while back, we discussed using a DNS hint to predict key shares and reduce 
> HelloRetryRequest, but this was dropped due to downgrade issues. In thinking 
> through post-quantum KEMs and the various transitions we'll have in the 
> future, I realized we actually need to address those downgrade issues now. 
> I've published a draft below which is my attempt at resolving this.
>
> We don't need a DNS hint for the current PQ transition—most TLS ecosystems 
> should stick to the one preferred option, and then clients can predict that 
> one and move on. However, I think we need to lay the groundwork for it now. 
> If today's round of PQ supported groups cannot be marked "prediction-safe" 
> (see document for what I mean by that), transitioning to the next PQ KEM 
> (e.g. if someone someday comes up with a smaller one that we're still 
> confident in!) will be extremely difficult without introducing downgrades.
>
> Thoughts?
>
> David
>
> -- Forwarded message -
> From: 
> Date: Mon, Sep 25, 2023 at 6:56 PM
> Subject: New Version Notification for 
> draft-davidben-tls-key-share-prediction-00.txt
> To: David Benjamin 
>
>
> A new version of Internet-Draft draft-davidben-tls-key-share-prediction-00.txt
> has been successfully submitted by David Benjamin and posted to the
> IETF repository.
>
> Name: draft-davidben-tls-key-share-prediction
> Revision: 00
> Title:TLS Key Share Prediction
> Date: 2023-09-25
> Group:Individual Submission
> Pages:11
> URL:  
> https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.txt
> Status:   
> https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/
> HTML: 
> https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html
> HTMLized: 
> https://datatracker.ietf.org/doc/html/draft-davidben-tls-key-share-prediction
>
>
> Abstract:
>
>This document clarifies an ambiguity in the TLS 1.3 key share
>selection, to avoid a downgrade when server assumptions do not match
>client behavior.  It additionally defines a mechanism for servers to
>communicate key share preferences in DNS.  Clients may use this
>information to reduce TLS handshake round-trips.
>
>
>
> The IETF Secretariat
>
>
> ___
> 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] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

[Loganaden Velvindron]

On Wed, 5 Apr 2023 at 06:32, Stephen Farrell  wrote:
>
>
> Hiya,
>
> On 05/04/2023 02:47, Sean Turner wrote:
> > A post IETF 116 bump to make sure folks get their reviews in. If you
> > look at the diffs from RFC 8446 you can see not that much has
> > changed. We will also take “I read it and it looks good” response.
>
> I looked at the diff between 8446bis-07 and 8446 and it seems
> fine to me. My only comment is that C.4 says one "SHOULD NOT
> reuse a key share" - I'd be happier if that was a "MUST NOT"
> but understand if we stick with SHOULD NOT. If there were a
> good reference showing that it's quite feasible to never
> deliberately re-use a key share, even at scale, that'd be a fine
> addition. (I don't have such a reference to offer,
> sorry;-)
>

Agreed. Overall, the document looks good.

> Cheers,
> 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

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Loganaden Velvindron]

I hope this moves forward.

On Wed, 29 Mar 2023 at 05:50, Christopher Wood  wrote:
>
> As discussed during yesterday's meeting, we would like to assess consensus 
> for moving draft-ietf-tls-hybrid-design forward with the following strategy 
> for allocating codepoints we can use in deployments.
>
> 1. Remove codepoints from draft-ietf-tls-hybrid-design and advance this 
> document through the process towards publication.
> 2. Write a simple -00 draft that specifies the target variant of 
> X25519+Kyber768 with a codepoint from the standard ranges. (Bas helpfully did 
> this for us already [1].) Once this is complete, request a codepoint from 
> IANA using the standard procedure.
>
> The intent of this proposal is to get us a codepoint that we can deploy today 
> without putting a "draft codepoint" in an eventual RFC.
>
> Please let us know if you support this proposal by April 18, 2023. Assuming 
> there is rough consensus, we will move forward with this proposal.
>
> Best,
> Chris, Joe, and Sean
>
> [1] https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-00
> ___
> 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] FW: New Version Notification for draft-mattsson-tls-psk-ke-dont-dont-dont-04.txt

[Loganaden Velvindron]

Hi John,


On Wed, Jan 11, 2023, 21:49 John Mattsson  wrote:

> Hi,
>
>
>
> Changes in -04:
>
> - Eric Rescorla commented that we should ask whether it's time to
> deprecate or at least Discourage psk_ke. Changed the psk_ke suggestion from
> “N” to “D”
>
>
> - Added that BoringSSL has chosen to not even implement psk_ke
>
>
>

I've also looked at LibreSSL quickly and it doesn't appear to support
psk_ke in their TLS 1.3 stack.


> - Eric Rescorla commented that he thinks the RFC 9150 algorithms should be
> marked as Discouraged. The document was updated with an evaluation and this
> suggestion.
>
>
>
> - The x25519 performance section was rewritten after a comment from Paul
> Wouters
>
>
>
> - Added evaluations and suggestions for the other TLS 1.3 parameters (
> ffdhe2048, rsa_pkcs1_sha256, rsa_pkcs1_sha384, and rsa_pkcs1_sha512) that
> BSI has introduced deadlines for.
>
>
> - Changed to standards track as the suggested IANA actions require
> Standards Action
>
>
> - Added introduction to explain RFC8447 and RFC8447bis
>
>
> - Added details on exactly which zero trust principles that are intended
> (comment from Eric Rescorla)
>
>
>
> Cheers,
>
> John
>
>
>
> *From: *internet-dra...@ietf.org 
> *Date: *Wednesday, 11 January 2023 at 18:24
> *To: *John Mattsson , John Mattsson <
> john.matts...@ericsson.com>
> *Subject: *New Version Notification for
> draft-mattsson-tls-psk-ke-dont-dont-dont-04.txt
>
>
> A new version of I-D, draft-mattsson-tls-psk-ke-dont-dont-dont-04.txt
> has been successfully submitted by John Preuß Mattsson and posted to the
> IETF repository.
>
> Name:   draft-mattsson-tls-psk-ke-dont-dont-dont
> Revision:   04
> Title:  NULL Encryption and Key Exchange Without Forward Secrecy
> are Dicouraged
> Document date:  2023-01-11
> Group:  Individual Submission
> Pages:  13
> URL:
> https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-04.txt
> Status:
> https://datatracker.ietf.org/doc/draft-mattsson-tls-psk-ke-dont-dont-dont/
> Html:
> https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-04.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-mattsson-tls-psk-ke-dont-dont-dont
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-psk-ke-dont-dont-dont-04
>
> Abstract:
>Massive pervasive monitoring attacks using key exfiltration and made
>possible by key exchange without forward secrecy have been reported.
>If key exchange without Diffie-Hellman is used, static exfiltration
>of the long-term authentication keys enables passive attackers to
>compromise all past and future connections.  Malicious actors can get
>access to long-term keys in different ways: physical attacks,
>hacking, social engineering attacks, espionage, or by simply
>demanding access to keying material with or without a court order.
>Exfiltration attacks are a major cybersecurity threat.  If NULL
>encryption is used an on-path attacker can read all application data.
>The use of psk_ke and NULL encryption are not following zero trust
>principles of minimizing the impact of breach and governments have
>already made deadlines for their deprecation.  This document sets the
>Recommended values of psk_ke, TLS_SHA256_SHA256, TLS_SHA384_SHA384,
>ffdhe2048 to "D" and the Recommended values of rsa_pkcs1_sha256,
>rsa_pkcs1_sha384, and rsa_pkcs1_sha512 to "N".
>
>
>
>
>
> The IETF Secretariat
> ___
> 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] consensus call: deprecate all FFDHE cipher suites

[Loganaden Velvindron]

On Fri, Dec 16, 2022, 11:41 Hal Murray  wrote:

>
> say...@gmail.com said:
> > For my part, I'm sick of "IoT" or "SCADA" or "embedded" vendors just
> > endlessly keeping old cipher suites alive. The unwise cost-cutting in
> those
> > areas does not constrain the rest of the internet.
>
> Agreeded, but the software maintainers can't just drop support for X
> because
> it has been deprecated.  There needs to be some plan with a schedule that
> gives downstream users time to get their act in gear.
>
> Should there be an IETF group to help coordinate things like this?  If
> nothing
> else, there should be a RFC explaining the problem to vendors planning to
> ship
> software that can't be updated -- and showing their potential customers
> what
> to consider.
>   Maybe data sheets should list the RFCs they depend upon -- with a big
> red
> arrow nwxt to the ones that have been obsoleted or deprecated.
>
> IoT and embedded are not the only problems.  There are many companies that
> run
> old stable software.  Ubuntu supports LTS releases for 5 years with 5 more
> available for a fee.
>   https://ubuntu.com/about/release-cycle
> Do we have to worry about this area?  Or will the companies like Ubuntu
> take
> care of their customers?
>
Pressure from auditors will force Ubuntu to help their paying customers to
update cryptographic primitives for compliance ?



>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> 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] consensus call: deprecate all FFDHE cipher suites

[Loganaden Velvindron]

I support.

On Tue, Dec 13, 2022, 18:47 Sean Turner  wrote:

> During the tls@IETF 115 session topic covering
> draft-ietd-tls-deprecate-obsolete-kex, the sense of the room was that there
> was support to deprecate all FFDHE cipher suites including well-known
> groups. This message starts the process to judge whether there is consensus
> to deprecate all FFDHE cipher suites including those well-known groups.
> Please indicate whether you do or do not support deprecation of FFDHE
> cipher suites by 2359UTC on 6 January 2023. If do not support deprecation,
> please indicate why.
>
> NOTE: We had an earlier consensus call on this topic when adopting
> draft-ietd-tls-deprecate-obsolete-kex, but the results were inconclusive.
> If necessary, we will start consensus calls on other issues in separate
> threads.
>
> Cheers,
> Chris, Joe, and Sean
> ___
> 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] sslkeylogfile

[Loganaden Velvindron]

I think that it's good to have a reference document regarding this.

I hope to see the work move forward.

On Tue, 25 Oct 2022 at 09:21, Martin Thomson  wrote:
>
> On Tue, Oct 25, 2022, at 16:09, Peter Gutmann wrote:
> > Well at the moment the web page defines what's used in practice and the spec
> > defines... something?  A hope for the future?  An extension to the current
> > usage?
>
> The exact same thing, just using different words and style.
>
> The intent is to provide a better, more stable reference.  For instance, the 
> NSS page has moved a few times recently.  I'm not sure that all links have 
> been updated, nor can I guarantee that firefox source docs will remain 
> stable.  And citing firefox source docs is awkward for some.
>
> ___
> 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] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Loganaden Velvindron]

I also support.

On Tue, Aug 17, 2021 at 11:19 PM Salz, Rich
 wrote:
>
> I still support adoption, as I said a couple of weeks ago. I also still think 
> we should consider merging this and 
> draft-aviram-tls-deprecate-obsolete-kex-00.
>
>
>
> I know that I’ve also said this before (can’t find it in my “sent mail” 
> folder), but the fact that some communities can still use this safely, or 
> must use it (for a variety of reasons usually around the infeasibility of 
> upgrading), doesn’t mean that the general populace should not be warned away 
> from doing these kinds of things.
>
>
>
> ___
> 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] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

[Loganaden Velvindron]

I also support adoption.

On Mon, Aug 9, 2021 at 10:16 PM Carrick Bartle
 wrote:
>
> I support adoption.
>
> On Jul 29, 2021, at 2:50 PM, Joseph Salowey  wrote:
>
> This is a working group call for adoption of Deprecating Obsolete Key 
> Exchange Methods in TLS  (draft-aviram-tls-deprecate-obsolete-kex-00).  There 
> was support for adopting this draft at the IETF 111 meeting.  Please review 
> the draft and post your comments to the list by Friday, August 13, 2021.
>
> Thanks,
>
> The TLS chairs
> ___
> 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

Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Loganaden Velvindron]

On Fri, Jan 22, 2021 at 7:30 AM Daniel Migault  wrote:
>
> Hi,
>
> I apology for responding so late - I missed the thread. I want this document 
> to be moved forward but so far I do not have the impression my concerns have 
> been addressed. I suppose that results from my lake of responsiveness and I 
> apology. Please find my response inline and let me know what can be achieved 
> reasonably.
>
> Yours,
> Daniel
>
>
> On Tue, Oct 27, 2020 at 11:34 PM Sean Turner  wrote:
>>
>>
>> Please note the comment about Section 3 suggests changing server behavior 
>> from SHOULD NOT to a MUST NOT.
>>
>> > On Oct 27, 2020, at 10:19, Daniel Migault via Datatracker 
>> >  wrote:
>> >
>> > Reviewer: Daniel Migault
>> > Review result: Ready with Nits
>> >
>> > Hi,
>> >
>> >
>> > I reviewed this document as part of the IoT Directorate's ongoing effort to
>> > review all IETF documents being processed by the IESG.  These comments were
>> > written primarily for the benefit of the Security Area Directors.  Document
>> > authors, document editors, and WG chairs should treat these comments just 
>> > like
>> > any other IETF Last Call comments.
>> >
>> > Review Results: Ready with Nits
>> >
>> > Please find my comments below.
>> >
>> > Yours,
>> > Daniel
>> >
>> >
>> > Deprecating MD5 and SHA-1 signature hashes in TLS 1.2
>> >  draft-ietf-tls-md5-sha1-deprecate-04
>> > [...]
>> >
>> > 1.  Introduction
>> >
>> >   The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is
>> >   specified in [RFC5246].  MD5 and SHA-1 have been proven to be
>> >   insecure, subject to collision attacks [Wang].  In 2011, [RFC6151]
>> >   detailed the security considerations, including collision attacks for
>> >   MD5.  NIST formally deprecated use of SHA-1 in 2011
>> >   [NISTSP800-131A-R2] and disallowed its use for digital signatures at
>> >   the end of 2013, based on both the Wang, et. al, attack and the
>> >   potential for brute-force attack.  In 2016, researchers from INRIA
>> >   identified a new class of transcript collision attacks on TLS (and
>> >   other protocols) that rely on efficient collision-finding algorithms
>> >   on the underlying hash constructions [Transcript-Collision].
>> >   Further, in 2017, researchers from Google and CWI Amsterdam
>> >   [SHA-1-Collision] proved SHA-1 collision attacks were practical.
>> >   This document updates [RFC5246] and [RFC7525] in such a way that MD5
>> >   and SHA-1 MUST NOT be used for digital signatures.  However, this
>> >   document does not deprecate SHA-1 in HMAC for record protection.
>> >
>> > 
>> > RFC6194 may be mentioned as a reference for
>> > not deprecating HMAC-SHA-1 as well as an
>> > additional reference to [NISTSP800-131A-R2].
>>
>> Are asking for something like this:
>>
>> OLD:
>>
>>   In 2011, [RFC6151] detailed the security considerations,
>>   including collision attacks for MD5.
>>
>> NEW:
>>
>>   In 2011, [RFC6151] [RFC6194] detailed the security considerations,
>>   including collision attacks for MD5 and SHA-1, respectively.
>>
>> > Reading the text the situation of HMAC with
>> > MD5 is unclear. Since we specify that SHA-1
>> > is not deprecated for HMAC we may specify
>> > the status for HMAC with MD5. Given RFC6151 I
>> > hope the reason is that MD5 and HMAC-MD5 has
>> > already been deprecated but I have not found
>> > this. Maybe that would worth mentioning it
>> > is deprecated already.
>> >
>> > 
>>
>> Are you asking for something like this:
>>
>> OLD:
>>
>>   However, this document does not deprecate SHA-1 in HMAC
>>   for record protection.
>>
>>   However, this  document does not deprecate MD-5 or SHA-1 HMAC
>>   for record protection.
>
> 
> maybe we could add these are still considered as secured at the time of 
> writing.  It is also tempting to add that given we deprecate sha1 and md5 in 
> the signature, it is tempting to suggest to use unless necessary hmac-sha256. 
>  I have commented the PR12
> 
>>
>> <
>> > [...]
>> >
>> > 2.  Signature Algorithms
>> >
>> >   Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms
>> >   extension.  If a client does not send a signature_algorithms
>> >   extension, then the server MUST abort the handshake and send a
>> >   handshake_failure alert, except when digital signatures are not used
>> >   (for example, when using PSK ciphers).
>> >
>> > 
>> > It seems to me that the server behavior might
>> > be defined as well. In our case this could be
>> > something around the lines the server MUST
>> > ignore MD5 and SHA1 values in the signature
>> > algorithm extension.
>> >
>> > 
>>
>> I guess that would be the way to absolutely stamp them out, but don’t we get 
>> the same result because the client is not sending the values in the 
>> signaure_algorithms extension?
>>
> 
> The reason I would maybe have preferred to have indications for the client 
> and the server is that it is always easier for a server to say that it is 
> following the specs than to indicate that the clie

Re: [TLS] Obsoleting SCSV in draft-ietf-tls-oldversions-deprecate

[Loganaden Velvindron]

On Tue, Nov 10, 2020 at 10:41 PM Yaron Sheffer  wrote:
>
> Hi,
>
> We are now revising RFC 7525 for the new world, and in general we are 
> following this draft. So, MUST NOT negotiate TLS 1.0 and 1.1. This brought up 
> the question of SCSV, which was new when RFC 7525 was published but has since 
> been widely implemented/deployed.
>
> I think marking the “oldversions” draft as “obsoletes RFC 7507 (SCSV)” is not 
> great from an ecosystem point of view. People will interpret it as “no need 
> to implement SCSV in new code, no need to expose it as a configuration option 
> in existing code”. And we know that some admins will continue to allow 
> downgrade to TLS 1.0/1.1 no matter what we tell them. IMO we should protect 
> these people from downgrade attacks, even if we disagree with their policy.
>
> So I would call for a more nuanced wording re: SCSV, something like 
> (paraphrasing EKR):
>

Not everybody was happy to implement SCSV:
e.g LibreSSL.

From: https://v4.freshbsd.org/commit/openbsd/src/9t8bOP5HFWMq1Big
"

  Reluctantly add server-side support for TLS_FALLBACK_SCSV.

   This allows for clients that willingly choose to perform a downgrade and
   attempt to establish a second connection at a lower protocol after the
   previous attempt unexpectedly failed, to be notified and have the second
   connection aborted, if the server does in fact support a higher protocol.

   TLS has perfectly good version negotiation and client-side fallback is
   dangerous. Despite this, in order to maintain maximum compatability with
   broken web servers, most mainstream browsers implement this. Furthermore,
   TLS_FALLBACK_SCSV only works if both the client and server support it and
   there is effectively no way to tell if this is the case, unless you control
   both ends.

   Unfortunately, various auditors and vulnerability scanners (including
   certain online assessment websites) consider the presence of a not yet
   standardised feature to be important for security, even if the clients do
   not perform client-side downgrade or the server only supports current TLS
   protocols.

"

> In the world where the only valid values of TLS are 1.2 and 1.3+, the TLS 1.3 
> fallback mechanism should render the SCSV unnecessary. However for existing 
> client and server implementations that still include support for earlier TLS 
> versions, SCSV should continue to be supported.
>
> Thanks,
> Yaron
>
>
> ___
> 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] Obsolete SCSV!? (was Re: AD review of draft-ietf-tls-oldversions-deprecate-06)

[Loganaden Velvindron]

On Fri, Oct 2, 2020 at 10:11 PM Loganaden Velvindron
 wrote:
>
> Please go ahead. I remembered a discussion (outside of the ietf) where
> not everybody agreed
> with it but reluctantly implemented it.
>

Found the commit message in LibreSSL:

"

Reluctantly add server-side support for TLS_FALLBACK_SCSV.

   This allows for clients that willingly choose to perform a downgrade and
   attempt to establish a second connection at a lower protocol after the
   previous attempt unexpectedly failed, to be notified and have the second
   connection aborted, if the server does in fact support a higher protocol.

   TLS has perfectly good version negotiation and client-side fallback is
   dangerous. Despite this, in order to maintain maximum compatability with
   broken web servers, most mainstream browsers implement this.

"
> On Fri, Oct 2, 2020 at 9:44 PM Sean Turner  wrote:
> >
> >
> >
> > > On Sep 23, 2020, at 08:43, Sean Turner  wrote:
> > >
> > > Hi! this issue was buried in the Ben’s review, but I think it is worth 
> > > getting some attention on.
> > >
> > >> On Aug 13, 2020, at 13:54, Benjamin Kaduk  wrote:
> > >>
> > >> On Wed, Aug 12, 2020 at 04:29:56PM -0400, Kathleen Moriarty wrote:
> > >>>
> > >>> On Sun, Jul 26, 2020 at 5:22 PM Benjamin Kaduk  wrote:
> > >>>>
> > >>>> - Similarly, the downgrade protection provided by the SCSV of RFC 7507
> > >>>> seems to be entirely obsolete.  Any implementation that is compliant
> > >>>> with this document will support only 1.2 or higher.  If it only
> > >>>> supports one version, no downgrade is possible; if it also supports
> > >>>> 1.3 or newer, the new downgrade-detection mechanism defined by TLS 1.3
> > >>>> applies, so the SCSV mechanism is entirely redundant (i.e., obsolete).
> > >>>> We could effectuate that status change in this document as well.
> > >>>>
> > >>>
> > >>> Has this been addressed in RFC8446?  If not, the specific downgrade
> > >>> examples are just listed as examples.  If a gap is left, then the full
> > >>> document should not be deprecated and made obsolete.  The text infers 
> > >>> other
> > >>> versions in my read.  I have not looked to see if this was addressed in
> > >>> RFC8446 yet though.
> > >>
> > >> I'd really like to get a few more people to weigh in on this one -- IIRC
> > >> David Benjamin and Martin Thomson had mentioned some thoughts in the chat
> > >> during the session at 108, and Ekr as author of 8446 would be expected to
> > >> have a good sense of what it does.
> > >>
> > >> The specific RFC 8446 mechanism here is described at
> > >> https://tools.ietf.org/html/rfc8446#section-4.1.3 : "TLS 1.3 has a
> > >> downgrade protection mechanism embedded in the server's random value.
> > >> [...]"
> > >>
> > >> While the RFC 8446 mechanism has the client do the actual detection of
> > >> downgrade, there's a MUST-level requirement on clients to make the check,
> > >> so from a specification point of view the check can be treated as 
> > >> reliable.
> > >> The RFC 7507 mechanism has the server do the detection, but I think the 
> > >> end
> > >> result is still the same: in an "downgraded" exchange between two honest
> > >> participants, the handshake fails and the downgrade is detected.
> > >>
> > >> Since the functionality is still useful, just superseded, this one seems
> > >> like a better fit for "obsoletes" (vs. "historic).
> > >>
> > >
> > > Right now, we have a list of RFCs draft-ietf-tls-oldversions-deprecate 
> > > will update. RFC 7507 "TLS Fallback Signaling Cipher Suite Value (SCSV) 
> > > for Preventing Protocol Downgrade Attacks" 
> > > (https://datatracker.ietf.org/doc/rfc7507/) is in this list. If you agree 
> > > with Ben’s logic then we would be move 7507 out of the list of “updates” 
> > > and adding an obsoletes header, i.e., “Obsoletes: 7507 (if approved)”, 
> > > and moving 7507 down in s1.1 to the obsoletes paragraph. While this might 
> > > seem like a minor point, this is the kind of the IESG loves to sink its 
> > > teeth into so have a WG opinion on this matter can make overcoming later 
> > > hurdles easier for the AD and doc shepherd.
> > >
> > > Thanks for the your time,
> > >
> > > spt (doc shepherd)
> >
> > All I have gone ahead and submitted a PR to address the point raised by Ben:
> > https://github.com/tlswg/oldversions-deprecate/pull/4
> >
> > spt
> > ___
> > 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] Obsolete SCSV!? (was Re: AD review of draft-ietf-tls-oldversions-deprecate-06)

[Loganaden Velvindron]

Please go ahead. I remembered a discussion (outside of the ietf) where
not everybody agreed
with it but reluctantly implemented it.

On Fri, Oct 2, 2020 at 9:44 PM Sean Turner  wrote:
>
>
>
> > On Sep 23, 2020, at 08:43, Sean Turner  wrote:
> >
> > Hi! this issue was buried in the Ben’s review, but I think it is worth 
> > getting some attention on.
> >
> >> On Aug 13, 2020, at 13:54, Benjamin Kaduk  wrote:
> >>
> >> On Wed, Aug 12, 2020 at 04:29:56PM -0400, Kathleen Moriarty wrote:
> >>>
> >>> On Sun, Jul 26, 2020 at 5:22 PM Benjamin Kaduk  wrote:
> 
>  - Similarly, the downgrade protection provided by the SCSV of RFC 7507
>  seems to be entirely obsolete.  Any implementation that is compliant
>  with this document will support only 1.2 or higher.  If it only
>  supports one version, no downgrade is possible; if it also supports
>  1.3 or newer, the new downgrade-detection mechanism defined by TLS 1.3
>  applies, so the SCSV mechanism is entirely redundant (i.e., obsolete).
>  We could effectuate that status change in this document as well.
> 
> >>>
> >>> Has this been addressed in RFC8446?  If not, the specific downgrade
> >>> examples are just listed as examples.  If a gap is left, then the full
> >>> document should not be deprecated and made obsolete.  The text infers 
> >>> other
> >>> versions in my read.  I have not looked to see if this was addressed in
> >>> RFC8446 yet though.
> >>
> >> I'd really like to get a few more people to weigh in on this one -- IIRC
> >> David Benjamin and Martin Thomson had mentioned some thoughts in the chat
> >> during the session at 108, and Ekr as author of 8446 would be expected to
> >> have a good sense of what it does.
> >>
> >> The specific RFC 8446 mechanism here is described at
> >> https://tools.ietf.org/html/rfc8446#section-4.1.3 : "TLS 1.3 has a
> >> downgrade protection mechanism embedded in the server's random value.
> >> [...]"
> >>
> >> While the RFC 8446 mechanism has the client do the actual detection of
> >> downgrade, there's a MUST-level requirement on clients to make the check,
> >> so from a specification point of view the check can be treated as reliable.
> >> The RFC 7507 mechanism has the server do the detection, but I think the end
> >> result is still the same: in an "downgraded" exchange between two honest
> >> participants, the handshake fails and the downgrade is detected.
> >>
> >> Since the functionality is still useful, just superseded, this one seems
> >> like a better fit for "obsoletes" (vs. "historic).
> >>
> >
> > Right now, we have a list of RFCs draft-ietf-tls-oldversions-deprecate will 
> > update. RFC 7507 "TLS Fallback Signaling Cipher Suite Value (SCSV) for 
> > Preventing Protocol Downgrade Attacks" 
> > (https://datatracker.ietf.org/doc/rfc7507/) is in this list. If you agree 
> > with Ben’s logic then we would be move 7507 out of the list of “updates” 
> > and adding an obsoletes header, i.e., “Obsoletes: 7507 (if approved)”, and 
> > moving 7507 down in s1.1 to the obsoletes paragraph. While this might seem 
> > like a minor point, this is the kind of the IESG loves to sink its teeth 
> > into so have a WG opinion on this matter can make overcoming later hurdles 
> > easier for the AD and doc shepherd.
> >
> > Thanks for the your time,
> >
> > spt (doc shepherd)
>
> All I have gone ahead and submitted a PR to address the point raised by Ben:
> https://github.com/tlswg/oldversions-deprecate/pull/4
>
> spt
> ___
> 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] Adoption call for draft-rescorla-tls-rfc8446-bis

[Loganaden Velvindron]

On Wed, Sep 2, 2020 at 8:21 PM Salz, Rich
 wrote:
>
> I support this and will help work on it.
>
I also support adoption.

> ___
> 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] Requesting working group adoption of draft-stebila-tls-hybrid-design

[Loganaden Velvindron]

I support adoption and I'm willing to review the document.

On Wednesday, February 12, 2020, Douglas Stebila  wrote:

> Dear TLS working group,
>
> We would like to request the working group adopt
> draft-stebila-tls-hybrid-design, "Hybrid key exchange in TLS 1.3", as
> a working group item.  We have updated the draft based on feedback
> we've received over the past few months, including from our
> presentations at IETF 104 and 105, and think the current version
> represents the view of the WG to date.
>
> https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/
>
> Cheers,
>
> Douglas
>
> ___
> 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] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2

[Loganaden Velvindron]

On Tue, May 14, 2019 at 10:57 PM Hubert Kario  wrote:

> On Tuesday, 14 May 2019 20:16:17 CEST Loganaden Velvindron wrote:
> > On Tue, May 14, 2019 at 3:24 PM Hubert Kario  wrote:
> > > On Tuesday, 14 May 2019 08:34:38 CEST Loganaden Velvindron wrote:
> > > > Latest draft is here:
> > > >
> https://www.ietf.org/id/draft-lvelvindron-tls-md5-sha1-deprecate-04.txt
> > >
> > > why did you drop SHA-1 from Section 4 and 5?
> >
> > It was done following this comment from David Cooper.
> >
> > "
> > [..] While they may be subject to collision attacks, SHA-1 is still
> > considered secure in cases in which collision resistance is not required,
> > and I do not believe that collision resistance is required when SHA-1 is
> > used to create the "signatures" in the ServerKeyExchange and
> > CertificateVerify messages.
> > "
>
> SLOTH paper disagrees on that as far as CertificateVerify message is
> concerned
>
> SP 800-52 rev-2 does not provide much in terms of justification why SLOTH
> paper would be wrong and allows for SHA-1 signatures only in TLS 1.0 and
> TLS
> 1.1, it does not explicitly state that SHA-1 signatures in TLS 1.2 are
> allowed...
>

Hello All,

We've updated the document based on the feedback we've got:

We've re-added deprecating sha-1 in ServerKeyExchange and CertificateVerify:
https://tools.ietf.org/html/draft-lvelvindron-tls-md5-sha1-deprecate-05

-- 
> 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2

[Loganaden Velvindron]

On Tue, May 14, 2019 at 3:24 PM Hubert Kario  wrote:

> On Tuesday, 14 May 2019 08:34:38 CEST Loganaden Velvindron wrote:
> > Latest draft is here:
> > https://www.ietf.org/id/draft-lvelvindron-tls-md5-sha1-deprecate-04.txt
>
> why did you drop SHA-1 from Section 4 and 5?
>
> It was done following this comment from David Cooper.
"
[..] While they may be subject to collision attacks, SHA-1 is still
considered secure in cases in which collision resistance is not required,
and I do not believe that collision resistance is required when SHA-1 is
used to create the "signatures" in the ServerKeyExchange and
CertificateVerify messages.
"



> the note about SHA-1 in HMAC applies to ciphersuites, to state explicitly
> that
> ciphersuites like TLS_DHE_RSA_WITH_AES_128_CBC_SHA are _not_ deprecated by
> it
>
> SKE and CV don't use HMAC
>
-- 
> 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2

[Loganaden Velvindron]

[comments in-line]

On Fri, May 10, 2019 at 5:47 AM Martin Thomson  wrote:

> It might pay to spend more time on explaining what you are trying to do.
>
> The goal appears to be to remove a dependency on signature schemes that
> include these weaker hash functions.  But the introduction just says that
> the functions are bad.
>
> We've updated the draft.


> You should be very clear about what effect this has on the use of SHA-1 in
> HMAC for record protection.  It looks like you don't intend to deprecate
> that.  Say that.
>
> Added.

> The change to the enum is silly.  Overall, I think that the updates to
> 5246 are unnecessary.  Concentrate on 7525.
>
> Removed change to enum.

> The 7525 text starts with "When using RSA", so it could be read to not
> apply to ECDSA.  That would be a mistake.  I recommend splitting the
> paragraph into talking about the group size (the first sentence) and a
> separate paragraph on hash functions used as part of the signing process.
>
> This change was also incorporated.

> As part of that, this probably needs to be a MUST: "Clients SHOULD
> indicate to servers that they request SHA-256, by using the "Signature
> Algorithms" extension defined in TLS 1.2."
>
> And then I think we should publish something.  Like David, I'm acutely
> aware of the compatibility hazard that this presents, but it's no less
> worth doing.
>
> We also agree with you.
Latest draft is here:
https://www.ietf.org/id/draft-lvelvindron-tls-md5-sha1-deprecate-04.txt

>
> On Fri, May 10, 2019, at 00:12, Loganaden Velvindron wrote:
> > Hi all,
> >
> > Following the recent thread on TLS 1.0 and TLS 1.1 deprecation, we
> > came up with a proposal to deprecate md5 and sha1 for digital
> > signatures in the TLS 1.2 spec.
> >
> > Please find the draft at this url:
> > https://tools.ietf.org/html/draft-lvelvindron-tls-md5-sha1-deprecate-03
> >
> > We look forward to your feedback.
> >
> > ___
> > 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] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2

[Loganaden Velvindron]

Hi all,

Following the recent thread on TLS 1.0 and TLS 1.1 deprecation, we
came up with a proposal to deprecate md5 and sha1 for digital
signatures in the TLS 1.2 spec.

Please find the draft at this url:
https://tools.ietf.org/html/draft-lvelvindron-tls-md5-sha1-deprecate-03

We look forward to your feedback.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

[Loganaden Velvindron]

I also believe that it's ready.

On Fri, Apr 26, 2019 at 5:49 AM Daniel Migault
 wrote:
>
> I believe the doc is fine as it is.
> Yours,
> Daniel
>
> On Thu, Apr 25, 2019 at 9:30 PM Viktor Dukhovni  
> wrote:
>>
>> > On Apr 12, 2019, at 7:28 PM, Christopher Wood  wrote:
>> >
>> > This is the working group last call for the "Deprecating TLSv1.0 and 
>> > TLSv1.1” draft available at:
>> >
>> >https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/
>> >
>> > Please review the document and send your comments to the list by April 26, 
>> > 2019.
>>
>> My concern is whether the time is yet nigh for TLS 1.0 to be disabled
>> in opportunistic TLS in SMTP, or whether TLS 1.0 remains sufficiently
>> common to cause deprecation to do more harm than good via unnecessary
>> downgrades to cleartext.
>>
>> I don't have survey numbers for SMTP TLS protocol versions across MTAs
>> generally to shed light on this, perhaps someone does.  What I do have
>> is numbers for those MTAs (not a representative sample) that have DANE
>> TLSA records (so presumably a greater focus on security).
>>
>> The observed version frequencies are approximately:
>>
>> TLS 1.0:  1%
>> TLS 1.1:  0%
>> TLS 1.2: 87%
>> TLS 1.3: 12%
>>
>> essentially regardless of whether I deduplicate by name, IP or name and IP.
>> The respective sample sizes are 5435, 6938 and 7959.
>>
>> So if a DANE-enabled sender were to disable TLS 1.0 today, approximately
>> 1% of the destination MX hosts would be broken and need remediation.  These
>> handle just of 189 mostly small SOHO domains out of the ~1.1 million total
>> DANE SMTP domains, but four handle enough email to show up on the Gmail
>> SMTP transparency report:
>>
>>   tu-darmstadt.de
>>   t-2.net
>>   t-2.com
>>   t-2.si
>>
>> So on the whole, the draft should proceed, but some caution may be 
>> appropriate
>> outside the browser space, before operators start switching off TLS 1.0 
>> support.
>>
>> I don't see an operational considerations section.  Nor much discussion of
>> "less mainstream" (than Web browser) TLS application protocols.  Would a few
>> words of caution be appropriate, or is it expected that by the time the RFC
>> starts to change operator behaviour the "market share" of TLS 1.0 will be
>> substantially lower than I see today even with SMTP, XMPP, NTTP and the like.
>>
>> [ I would speculate that TLS 1.0's share is noticeably higher among MTAs
>>   generally than among the bleeding-edge MTAs that have published DANE TLSA
>>   RRs. ]
>>
>> --
>> 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SK filtering on SNI, blocking ESNI

[Loganaden Velvindron]

On Wed, Feb 13, 2019 at 1:32 PM Joseph Lorenzo Hall  wrote:

> It appears South Korea has started censoring traffic across all ISPs based
> on SNI [1], [2]. Nick points out that they seem to be blocking ESNI
> entirely [3].
>
> [1]: https://bugzil.la/1494901#c3
> [2]: https://news.joins.com/article/23363557
> [3]: https://twitter.com/grittygrease/status/1095530153319358465?s=21
>
>
That's quite extreme.

> --
> Joseph Lorenzo Hall
> Chief Technologist, Center for Democracy & Technology [https://www.cdt.org
> ]
> 1401 K ST NW STE 200, Washington DC 20005-3497
> e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871
> --
> Joseph Lorenzo Hall
> Chief Technologist, Center for Democracy & Technology [https://www.cdt.org
> ]
> 1401 K ST NW STE 200, Washington DC 20005-3497
> e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871
> ___
> 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] Proposed Errata for rfc5246

[Loganaden Velvindron]

Hi folks,

Bob Beck of OpenBSD/LibreSSL reported this issue with an implementation:
"
Fun fact: The TLS 1.2 signature algorithms extension is sent in client
preference order. http://outlook.office365.com  
then chooses the least preferred. every time.
Additional fun fact: I believe it is still standards compliant. RFC5246
says only that it must be sent by the client in preference order. It does
not say the server must respect the order.
"
My suggestion would be something like:
Section 7.4.1.4.1 .
current text:

Servers MUST NOT send this extension. TLS servers MUST support receiving
this extension.
Suggestion:
Servers MUST NOT send this extension. TLS servers MUST support receiving
this extension. TLS servers MUST respect the order in which the signature
algorithms are sent by the client.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG adoption call: draft-wood-tls-ticketrequests

[Loganaden Velvindron]

On Wednesday, November 7, 2018, Sean Turner  wrote:

> At TLS@IETF103, there was consensus in the room to adopt
> draft-wood-tls-ticketrequests.  This message is to confirm that consensus.
> If you do not support adoption of draft-wood-tls-ticketrequests as WG item
> please say so by 2359UTC on 30 November 2018 (and say why).
>
> Thanks,
> Joe and Sean

I support adoption of this draft.


> ___
> 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] Drop "1.x" from future TLS version names?

[Loganaden Velvindron]

On Mon, Aug 20, 2018 at 7:28 PM, Tony Arcieri  wrote:
> Apologies if the last thing people want to talk about right now is the next
> version of TLS.
>
> There was much discussion about bumping TLS 1.3's version number to "TLS 4"
> or thereabouts (so as to be higher than "SSLv3"). The ship has sailed on
> that and it is "TLS 1.3".
>
> I think there was widespread agreement that TLS 1.3 represented something a
> bit more substantial than a minor version bump, and a desire to have a TLS
> version number bigger than the SSL version number lest people get confused
> and deploy SSLv3 instead of TLS 1.3.
>
> Modest proposal: TLS 1.4 => TLS 4
>
> I bring this up so soon because I think a lot of the pushback regarding
> doing this before was due to changing the version so late in the development
> cycle.

I think that it's too late for that now.

>
> --
> Tony Arcieri
>
> ___
> 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] WG adoption call: draft-moriarty-tls-oldversions-diediedie

[Loganaden Velvindron]

I support the adoption.

On Friday, August 17, 2018, Sean Turner  wrote:

> At the TLS@IETF102 session, there seemed to be some interest in adopting
> draft-moriarty-tls-oldversions-diediedie as a WG item. This email is to
> determine whether there is WG consensus to adopt this draft as a WG item.
> If you would like for this draft to become a WG document and you are
> willing to review it as it moves through the process, then please let the
> list know by 2359UTC 20180831.  If you are opposed to this being a WG
> document, please say so (and say why).
>
> Note that we will suggest replacing “diediedie" with “deprecate" in the
> adopted draft’s name to address the naming comment raised during the
> meeting.
>
> Thanks,
> Chris, Joe and Sean
> ___
> 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] The TLS WG has placed draft-moriarty-tls-oldversions-diediedie in state "Call For Adoption By WG Issued"

[Loganaden Velvindron]

I support the adoption

On Friday, August 17, 2018, IETF Secretariat <
ietf-secretariat-re...@ietf.org> wrote:

>
> The TLS WG has placed draft-moriarty-tls-oldversions-diediedie in state
> Call For Adoption By WG Issued (entered by Sean Turner)
>
> The document is available at
> https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/
>
> ___
> 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] RFC 8446 on The Transport Layer Security (TLS) Protocol Version 1.3

[Loganaden Velvindron]

Indeed. It's been a long road to the final publication of the RFC.
Well done to everybody who put in the effort.

On Sat, Aug 11, 2018 at 3:43 PM, Kathleen Moriarty
 wrote:
> Congratulations to all who contributed!  In addition to EKR & the chairs, 
> thank you also to Ben who assisted with all of the final checks as the 
> responsible AD for this part of the process.
>
> Kathleen
>
> Sent from my mobile device
>
>> On Aug 10, 2018, at 7:56 PM, Benjamin Kaduk  wrote:
>>
>> A big congratulations and thanks to Ekr, the chairs, Kathleen, and all the
>> researchers and contributors who helped make this happen!
>> I'm looking forward to seeing the deployment share grow as we get the final
>> version out in the wild!
>>
>> -Ben
>>
>>> On Fri, Aug 10, 2018 at 04:54:34PM -0700, rfc-edi...@rfc-editor.org wrote:
>>> A new Request for Comments is now available in online RFC libraries.
>>>
>>>
>>>RFC 8446
>>>
>>>Title:  The Transport Layer Security (TLS) Protocol
>>>Version 1.3
>>>Author: E. Rescorla
>>>Status: Standards Track
>>>Stream: IETF
>>>Date:   August 2018
>>>Mailbox:e...@rtfm.com
>>>Pages:  160
>>>Characters: 337736
>>>Obsoletes:  RFC 5077, RFC 5246, RFC 6961
>>>Updates:RFC 5705, RFC 6066
>>>
>>>I-D Tag:draft-ietf-tls-tls13-28.txt
>>>
>>>URL:https://www.rfc-editor.org/info/rfc8446
>>>
>>>DOI:10.17487/RFC8446
>>>
>>> This document specifies version 1.3 of the Transport Layer Security
>>> (TLS) protocol.  TLS allows client/server applications to communicate
>>> over the Internet in a way that is designed to prevent eavesdropping,
>>> tampering, and message forgery.
>>>
>>> This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077,
>>> 5246, and 6961.  This document also specifies new requirements for
>>> TLS 1.2 implementations.
>>>
>>> This document is a product of the Transport Layer Security Working Group of 
>>> the IETF.
>>>
>>> This is now a Proposed Standard.
>>>
>>> STANDARDS TRACK: This document specifies an Internet Standards Track
>>> protocol for the Internet community, and requests discussion and suggestions
>>> for improvements.  Please refer to the current edition of the Official
>>> Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
>>> standardization state and status of this protocol.  Distribution of this
>>> memo is unlimited.
>>>
>>> This announcement is sent to the IETF-Announce and rfc-dist lists.
>>> To subscribe or unsubscribe, see
>>>  https://www.ietf.org/mailman/listinfo/ietf-announce
>>>  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>>>
>>> For searching the RFC series, see https://www.rfc-editor.org/search
>>> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
>>>
>>> Requests for special distribution should be addressed to either the
>>> author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
>>> specifically noted otherwise on the RFC itself, all RFCs are for
>>> unlimited distribution.
>>>
>>>
>>> The RFC Editor Team
>>> Association Management Solutions, LLC
>>>
>>
>> ___
>> 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

Re: [TLS] WG adoption call: draft-rescorla-tls-esni

[Loganaden Velvindron]

I support the adoption as well.

On Thu, Jul 26, 2018 at 9:20 PM, Short, Todd
 wrote:
> I support WG adoption.
>
>
>
> --
>
> -Todd Short
>
> // tsh...@akamai.com
>
> // "One if by land, two if by sea, three if by the Internet."
>
>
>
>
>
> From: Joseph Salowey 
> Date: Tuesday, July 24, 2018 at 10:18 PM
> To: "" 
> Subject: [TLS] WG adoption call: draft-rescorla-tls-esni
>
>
>
>
> The sense of the TLS@IETF102 room was the the WG should adopt
> https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ as a WG item.
> But, we need to confirm this on list.  If you would like for this draft to
> become a WG document and you are willing to review it as it moves through
> the process, then please let the list know by 2359UTC 20180807.  If you are
> opposed to this being a WG document, please say so (and say why).
>
> Note that the draft has been marked as a "Candidate for WG Adoption” in the
> datatracker.
>
>
>
>
>
>
> ___
> 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] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Loganaden Velvindron]

On Mon, Jul 9, 2018 at 8:54 PM, Eric Rescorla  wrote:
> Thanks for writing this.
>
> I would be in favor of deprecating old versions of TLS prior to 1.2. Firefox
> Telemetry shows that about 1% of our connections are TLS 1.1 (on the same
> data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible.
>
> This is probably a higher number than we'd be comfortable turning off
> immediately, but it is probably worth starting the process.
>

I'm also in favour. Many banks/instituion in developing countries are
moving to deprecate tls v1.0 and tls v1.1.

As I commented on github:
SSLpulse shows how many top websites support tls 1.2 (92.8%) and this
number is increasing (0.5%):

https://www.ssllabs.com/ssl-pulse/

KeyCDN and digicert have also announced their intentions to deprecate
tls 1.0 and tls 1.1.

https://github.com/sftcd/tls-oldversions-diediedie/commit/a0d6c160d922bd7f52a917884823114c90932291



> -Ekr
>
>
> On Mon, Jul 9, 2018 at 9:40 AM, Kathleen Moriarty
>  wrote:
>>
>> Hello,
>>
>> Stephen and I posted the draft below to see if the TLS working group
>> is ready to take steps to deprecate TLSv1.0 and TLSv1.1.  There has
>> been a recent drop off in usage for web applications due to the PCI
>> Council recommendation to move off TLSv1.0, with a recommendation to
>> go to TLSv1.2 by June 30th.  NIST has also been recommending TLSv1.2
>> as a baseline.  Applications other than those using HTTP may not have
>> had the same reduction in usage.  If you are responsible for services
>> where you have a reasonable vantage point to gather and share
>> statistics to assess usage further, that could be helpful for the
>> discussion.  We've received some feedback that has been incorporated
>> into the working draft and feelers in general have been positive.  It
>> would be good to know if there are any show stoppers that have not
>> been considered.
>>
>> https://github.com/sftcd/tls-oldversions-diediedie
>>
>> Thanks in advance,
>> Kathleen
>>
>>
>> -- Forwarded message --
>> From:  
>> Date: Mon, Jun 18, 2018 at 3:05 PM
>> Subject: New Version Notification for
>> draft-moriarty-tls-oldversions-diediedie-00.txt
>> To: Stephen Farrell , Kathleen Moriarty
>> 
>>
>>
>>
>> A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt
>> has been successfully submitted by Stephen Farrell and posted to the
>> IETF repository.
>>
>> Name:   draft-moriarty-tls-oldversions-diediedie
>> Revision:   00
>> Title:  Deprecating TLSv1.0 and TLSv1.1
>> Document date:  2018-06-18
>> Group:  Individual Submission
>> Pages:  10
>> URL:
>>
>> https://www.ietf..org/internet-drafts/draft-moriarty-tls-oldversions-diediedie-00.txt
>>
>> Status:
>> https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/
>> Htmlized:
>> https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00
>> Htmlized:
>>
>> https://datatracker.ietf.org/doc/html/draft-moriarty-tls-oldversions-diediedie
>>
>>
>> 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 profiiles 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 the backward compatibility sections of TLS RFCs
>>[[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1.  This
>>document also updates RFC 7525.
>>
>>
>>
>>
>> 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.
>>
>> The IETF Secretariat
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>> ___
>> 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

Re: [TLS] Update on TLS 1.3 Middlebox Issues

[Loganaden Velvindron]

On Sat, Oct 7, 2017 at 12:16 AM, Eric Rescorla  wrote:
> Hi folks,
>
> In Prague I mentioned that we were seeing evidence of increased
> failures with TLS 1.3 which we believed were due to middleboxes. In
> the meantime, several of us have done experiments on this, and I
> wanted to provide an update.
>
> The high-order bit is that *negotiating* TLS 1.3 seems to cause
> increased failures with a variety of middleboxes (it’s generally safe
> to offer TLS 1.3 to servers which don’t support it). The measured
> incremental error rates vary quite a bit, ranging from minimal
> (Facebook) to ~1.5% (Firefox) and ~3.4% (Chrome). Each of us is using
> a slightly different methodology (organic versus forced traffic) and
> different populations (mobile, desktop, enterprise, etc), but it does
> seem like there is a nontrivial failure rate. At this point, we have
> two options:
>
> - Fall back to TLS 1.2 (as we have unfortunately done for previous releases)
> - Try to make small adaptations to TLS 1.3 to make it work better with
> middleboxes.
>

We (hackers.mu) ran tests across different Mobile & FTTH providers,
and large wifi hotspot vendors across the island of Mauritius:

Mauritius Telecom FTTH: no issues with TLS 1.3
Emtel (mobile): no issues with TLS 1.3
Mauritius Telecom (mobile): no issues with TLS 1.3
AlwaysOn: Gateway has issues with TLS 1.3 (draft-18), when forcing all
HTTPS traffic to their HTTPS web-based portal.

Before authentication via SSL/TLS:


./bin/openssl s_client -connect tls13.crypto.mozilla.org:443 -tls1_3
-CApath=/etc/ssl/certs/
CONNECTED(0003)
140130750743872:error:14094410:SSL routines:ssl3_read_bytes:sslv3
alert handshake failure:ssl/record/rec_layer_s3.c:1471:SSL alert
number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 184 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
SSL-Session:
Protocol : TLSv1.3
Cipher : 
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1509976305
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---

I'm reaching out to the AlwaysOn service, which appears to be quite
well popular in South Africa as well.

//Logan
C-x-C-c

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Separate APIs for 0-RTT

[Loganaden Velvindron]

On Tue, Jun 13, 2017 at 2:54 PM, Ilari Liusvaara
 wrote:
> On Tue, Jun 13, 2017 at 09:28:49AM +0100, Eric Rescorla wrote:
>> The current text says:
>>
>>0-RTT data has very different security properties from data
>>transmitted after a completed handshake: it can be replayed.
>>Implementations SHOULD provide different functions for reading and
>>writing 0-RTT data and data transmitted after the handshake, and
>>SHOULD NOT automatically resend 0-RTT data if it is rejected by the
>>server.
>>
>> I think the second piece of guidance (about automatic re-send) is still
>> good but it seems like implementations are mostly converging on a single
>> API. Of the implementations I know, NSS, BoringSSL (I think), and Mint have
>> a single API and OpenSSL's use of two APIs is an outlier. I don't think
>> it's helpful to have a SHOULD that a lot of people violate, especially when
>> this also indicates we don't have consensus on this SHOULD.
>>
>> I propose we remove this recommendation in favor of one which simply says
>> that implementations should need applications to opt-in to 0-RTT. That
>> would allow implementations to have either API.
>
> I think it is VERY bad idea for TLS client library to do 0-RTT without
> application explicitly opting in to that (e.g., via setting a special
> setting, or using API call sequences that didn't work at all for
> n-RTT).
>

I also agree here.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)

[Loganaden Velvindron]

On Tue, Jan 12, 2016 at 3:42 AM, Dave Garrett  wrote:
> On Monday, January 11, 2016 06:13:37 pm Tony Arcieri wrote:
>> My understanding is TLS 1.2 specifically was amended to allow MD5
>> signatures even though this was not the case in previous TLS versions, or
>> at least that was the claim of the miTLS presenters on SLOTH at
>> RealWorldCrypto 2016.
>>
>> If this is the case, this seems like a big regression in TLS 1.2.
>
> I'd like to propose killing the low hanging fruit first, and then continue to 
> build on top of that.
>
> No sane person disputes that MD5 needs to be eradicated ASAP. We're keeping 
> MD5||SHA1 in old TLS for compatibility and we are well aware that needs to go 
> eventually too. Thus, I suggest we publish an MD5 diediedie standards track 
> RFC to prohibit ALL standalone MD5 use in ALL IETF protocols/standards. 
> Constructions using MD5 with something else (namely MD5||SHA1) would also be 
> explicitly recommended against in existing specifications, and explicitly 
> prohibited in all new drafts (even if unlikely).
>
> Also, when I say "prohibited" here, I mean _completely_. No MD5 function 
> should remain in the relevant codebase; if MD5||SHA1 support is continued, 
> there should be one function that does only that without any way to get a 
> plain MD5 hash. (and no "it's fine for this" junk; non-broken hashes are also 
> fine for that, and if you're wrong, it's safer) There are too many 
> implementation bugs in this realm to not state this explicitly [0].
>

I completely agree. At least one open source SSL/TLS implementation is
looking at purging their code of MD5 functions.


> Note that continued support of trust anchors with MD5 hashes is not dependent 
> on this, as we've already agreed they don't need to be validated. (they need 
> to be phased out, but with less urgency) If used within this specific 
> context, nothing even needs the ability to understand MD5 hashes at all in 
> order to handle these; the certificate as a whole is trusted or not.
>
>
> Dave
>
>
> PS
> To whomever came up with the "diediedie" term, thank you. ;)
>
>
> [0] Note the 3 disabled-but-accepted bugs listed here:
> https://www.mitls.org/pages/attacks/SLOTH#disclosure
>
> ___
> 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] Early code point assignment request for curve25519 and curve448

[Loganaden Velvindron]

On Sat, Nov 14, 2015 at 6:14 PM, Adam Langley  wrote:
> The IESG conflicts review for
> https://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/ has now
> completed without issue[1].
>
> The editor's copy of the 1.3 spec contains code points for these
> curves[2], specifically:
>
>   // ECDH functions.
>ecdh_x25519 (29), ecdh_x448 (30),
>
>// Signature curves.
>eddsa_ed25519 (31), eddsa_ed448 (32),
>
> I'd like to request that these code points for early assignment.
>
> [1] 
> https://mailarchive.ietf.org/arch/msg/ietf-announce/MWmqSxBZxWPEt6glXJZvXg5lMS4
> [2] https://tlswg.github.io/tls13-spec/#rfc.section.6.3.2.2
>

I support this code point assignment.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 - Support for compression to be removed

[Loganaden Velvindron]

On Sat, Sep 19, 2015 at 11:46 AM, Kurt Roeckx  wrote:

> On Thu, Sep 17, 2015 at 01:23:19PM +, Alewa, Christos wrote:
> > Since we at HOB, use SSL to maintain long-running VPN connections, might
> it be possible to - at least - maintain the status quo of the TLS -
> protocol in this aspect, enabling and disabling compression if needed?
>
> If compression is dropped at the TLS layer, you can still do it at
> the layer above it.
>
>
Indeed. And, it's probably a better idea to do it in the layer above.



>
> Kurt
>
> ___
> 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