Re: [TLS] sect571r1

[Benjamin Beurdouche]

Hey,

Except if someone has a real need for it,
I would favour removing p571 and keep secp521r1 as the maximum …

Cheers,
B.


> On 15 Jul 2015, at 20:13, Dave Garrett  wrote:
> 
> In PR 188 for TLS 1.3, I pruned down the allowed elliptic curves to just the 
> ones actually used. (per Sean's recommendation) One point of discussion 
> between Eric and myself: sect571r1. I'm in favor of keeping it, but not very 
> strongly. Eric suggested removing it. It does get some use, though quite a 
> bit less than the others.
> 
> The main reason I think this warrants discussion is that dropping it would 
> drop the maximum bits here, which whilst obviously not the only factor to 
> take into account, will possibly not be desired by some. The main arguments 
> for ditching is probably that it might not be safely implemented and nobody 
> actually needs something this big.
> 
> So, should it stay or should it go now? Opinions?
> 
> 
> Dave
> 
> ___
> 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] 4492 ECDH_anon

[Benjamin Beurdouche]

>> I have never understood why 4492 doesn't claim forward secrecy for
>> ECDH_anon suites.  Can someone explain why this doesn't have an 'E’?
> 
> I wasn’t there for the original 4492, but I think it’s because the old 
> anonymous ciphersuites were called DH_anon (no E). 
> 
> They both provide forward secrecy.

This is very confusing …

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

Re: [TLS] ban more old crap

[Benjamin Beurdouche]

> On 25/07/15 06:46, Viktor Dukhovni wrote:
>> I hope, that by ~2017, RC4 will no longer be required either, and
>> we'll be able to disable RC4 in Postfix at that time.
> 
> Seems to me that should be a reasonable match for expecting to see
> TLS1.3 getting deployed in lots of parts of the mail infrastructure,
> so that date would argue to not support rc4 at all in TLS1.3 in my
> conclusion (not that I know much about mail deployment trends).
> 
> And if we have any support for rc4 in TLS1.3 it'll end up a footgun
> that'll damage many toes, so count me amongst those arguing for no
> rc4 (or similar) at all in TLS1.3.

+1, though, my understanding was that RC4 was already out of TLS 1.3..
In general I think we could all agree that we should never keep broken stuff in 
TLS even if it is used a lot…

Best,
B.


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

Re: [TLS] Our fearless leader

[Benjamin Beurdouche]

Wow, he brings the word fearless to another level =P


> On 28 Jul 2015, at 01:11, Salz, Rich  wrote:
> 
> Sean, at the CFRG meeting last week, wasn't bothered at all when all the 
> seats were taken.

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

Re: [TLS] Data volume limits

[Benjamin Beurdouche]

> On 15 Dec 2015, at 22:17, Watson Ladd  wrote:
> 
> I don't think that's what I intended: I think the limit should be
> ciphersuite specific. Unfortunately that requires more work.
> 
> On Tue, Dec 15, 2015 at 4:15 PM, Eric Rescorla  wrote:
>> 
>>> I wanted to get people's opinions on whether that's actually what we want
>>> or whether we should (as is my instinct) allow people to use ChaCha
>>> for longer periods.

IMHO, if we differentiate the limit depending on the ciphersuite, it will be 
more complex to handle and cause problems at some point.
I would rather have a single value in the spec that is safe for all allowed 
ciphersuites, rekey more frequently and leave people take their own risks by 
setting higher limits if they do not negotiate AES-GCM (for example).

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

Re: [TLS] RSA-PSS in TLS 1.3

[Benjamin Beurdouche]

> PKCS #1 1.5 is a real problem. The last PKCS #1 1.5 signature related
> vuln that could've been prevented by using RSA-PSS was found 2 months
> ago [1]. The last one in a major implementation (BERserk) was in 2014.
> 
> tl;dr: I don't think supporting PKCS #1 1.5 in TLS 1.3 is reasonable.
> Let's not repeat the mistakes from the past.

I agree, we started 1.3 by removing old and deprecated stuff. We should not 
allow it now and risk weakening our work...

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

Re: [TLS] Adoption call for draft-rescorla-tls-rfc8446-bis

[Benjamin Beurdouche]

I support adoption of this work.
B.

> On Sep 2, 2020, at 6:18 PM, Christopher Wood  wrote:
> 
> This email begins the adoption call for draft-rescorla-tls-rfc8446-bis. As 
> mentioned [1], this updates language and fixes some errata against RFC8446 
> (as identified below). No other semantic changes were made.
> 
> Errata fixed:
> - https://www.rfc-editor.org/errata/eid6141, via 
> https://github.com/ekr/tls13-spec/issues/54
> - https://www.rfc-editor.org/errata/eid6205, via 
> https://github.com/ekr/tls13-spec/issues/53
> - https://www.rfc-editor.org/errata/eid6204, via 
> https://github.com/ekr/tls13-spec/issues/52
> - https://www.rfc-editor.org/errata/eid6150, via 
> https://github.com/ekr/tls13-spec/issues/51
> - https://www.rfc-editor.org/errata/eid6147, via 
> https://github.com/ekr/tls13-spec/issues/49
> - https://www.rfc-editor.org/errata/eid6139, via 
> https://github.com/ekr/tls13-spec/issues/46
> - https://www.rfc-editor.org/errata/eid6138, via 
> https://github.com/ekr/tls13-spec/issues/45
> - https://www.rfc-editor.org/errata/eid6137, via 
> https://github.com/ekr/tls13-spec/issues/44
> - https://www.rfc-editor.org/errata/eid6135, via 
> https://github.com/ekr/tls13-spec/issues/43
> - https://www.rfc-editor.org/errata/eid6128, via 
> https://github.com/ekr/tls13-spec/issues/42
> - https://www.rfc-editor.org/errata/eid6125, via 
> https://github.com/ekr/tls13-spec/issues/39
> - https://www.rfc-editor.org/errata/eid6122, via 
> https://github.com/ekr/tls13-spec/issues/37
> - https://www.rfc-editor.org/errata/eid6152, via 
> https://github.com/ekr/tls13-spec/issues/33
> - https://www.rfc-editor.org/errata/eid6146, via 
> https://github.com/ekr/tls13-spec/issues/31
> - https://www.rfc-editor.org/errata/eid6145, via 
> https://github.com/ekr/tls13-spec/issues/30
> - https://www.rfc-editor.org/errata/eid6142, via 
> https://github.com/ekr/tls13-spec/issues/28
> - https://www.rfc-editor.org/errata/eid6136, via 
> https://github.com/ekr/tls13-spec/issues/27
> - https://www.rfc-editor.org/errata/eid6123, via 
> https://github.com/ekr/tls13-spec/issues/26
> - https://www.rfc-editor.org/errata/eid5868, via 
> https://github.com/ekr/tls13-spec/issues/24
> - https://www.rfc-editor.org/errata/eid5682, via 
> https://github.com/ekr/tls13-spec/issues/23
> - https://www.rfc-editor.org/errata/eid5483, via 
> https://github.com/ekr/tls13-spec/issues/22
> - https://www.rfc-editor.org/errata/eid5627
> - https://www.rfc-editor.org/errata/eid5976
> 
> Errata ready to close with no action:
> - https://www.rfc-editor.org/errata/eid6148
> - https://www.rfc-editor.org/errata/eid6144
> - https://www.rfc-editor.org/errata/eid6140
> - https://www.rfc-editor.org/errata/eid6127
> - https://www.rfc-editor.org/errata/eid6126
> - https://www.rfc-editor.org/errata/eid6124
> - https://www.rfc-editor.org/errata/eid6121
> - https://www.rfc-editor.org/errata/eid6120
> - https://www.rfc-editor.org/errata/eid5717
> - https://www.rfc-editor.org/errata/eid6151
> - https://www.rfc-editor.org/errata/eid6143
> - https://www.rfc-editor.org/errata/eid5874
> 
> Please let the WG know if you support adoption, and if so, are willing to 
> contribute to the discussion and review changes going forward. If you oppose 
> adoption, please explain why. 
> 
> The document may be found here:
> 
>   https://datatracker.ietf.org/doc/draft-rescorla-tls-rfc8446-bis/
> 
> This call for adoption will conclude on September 16.
> 
> Best,
> Chris, on behalf of the chairs
> 
> [1] https://mailarchive.ietf.org/arch/msg/tls/bLPs94FGzzmjNirCn2yf-FFPfqo/
> 
> ___
> 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 "Secure Negotiation of Incompatible Protocols in TLS"

[Benjamin Beurdouche]

I support adoption.
B.

> On Jul 29, 2021, at 10:22 PM, Christopher Wood  wrote:
> 
> Based on positive feedback during this week's meeting, we'd like to start an 
> adoption call for "Secure Negotiation of Incompatible Protocols in TLS." The 
> document may be found here:
> 
>   https://datatracker.ietf.org/doc/draft-thomson-tls-snip/
> 
> And the source may be found here:
> 
>   https://github.com/martinthomson/snip
> 
> This call for adoption will conclude on August 13.
> 
> Thanks, 
> Chris, for the 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

Re: [TLS] RFC 8446 on The Transport Layer Security (TLS) Protocol Version 1.3

[Benjamin Beurdouche]

Congratulations everyone !! :)
B.

> On Aug 10, 2018, at 4: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

Re: [TLS] WG adoption call: draft-moriarty-tls-oldversions-diediedie

[Benjamin Beurdouche]

I support adoption

> On Aug 17, 2018, at 10:32 AM, 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



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Benjamin Beurdouche]

> The WG is chartered to make TLS a fast, secure, confidential transport
> layer.  Let's keep the charter goals in mind.
> 
>--dkg

+ 1

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

Re: [TLS] Binder key labels for imported PSKs

[Benjamin Beurdouche]

Hi Chris,

I expect that the idea is to have key separation for the binder key depending 
on the usage. Having this kind of property is always a good practice, so I 
agree with Jonathan on this.

B.



> On Sep 3, 2019, at 1:29 AM, Christopher Wood  wrote:
> 
> Hi folks,
> 
> 
> Per Jonathan Hoyland's recommendation, we're considering adding a new 
> binder_key label ("imp binder") for imported PSKs. Specifically, this changes 
> the key schedule from this:
> 
> ~~~
>  0
>  |
>  v
>PSK ->  HKDF-Extract = Early Secret
>  |
>  +-> Derive-Secret(., "ext binder" | "res binder", "")
>  | = binder_key
> ~~~
> 
> to this:
> 
> ~~~
>  0
>  |
>  v
>PSK ->  HKDF-Extract = Early Secret
>  |
>  +-> Derive-Secret(., "ext binder"
>  |  | "res binder"
>  |  | "imp binder", "")
>  | = binder_key
> ~~~
> 
> Details can be found in the PR [1]. 
> 
> This does not seem to affect the interoperability story (imported keys are 
> further differentiated from non-imported keys). However, it's non trivial, so 
> we'd like feedback from the group before merging the change.
> 
> Thanks!
> Chris (no hat)
> 
> [1] https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/10
> 
> ___
> 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-ctls

[Benjamin Beurdouche]

I support adoption.
B.

> On Nov 21, 2019, at 6:53 AM, Salz, Rich  wrote:
> 
> 
>> 
>>   I think it's a good starting point. I support adoption.
> 
> Strongly agree.
> 
> ___
> 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] Re-chartering TLS

[Benjamin Beurdouche]

LGTM, I agree with using “resource" instead of “size”…
My understanding is that “security” is broad enough to cover new authentication 
mechanisms
and that “privacy" will be broad enough to cover “metadata protection” if 
needed, correct?
B.

> On Jan 17, 2020, at 4:31 AM, Christopher Wood  wrote:
> 
> Hi folks,
> 
> As discussed in Singapore, it's time to re-charter the working group to 
> reflect ongoing (e.g., Exported Authenticators and Encrypted SNI/CH) and 
> future work (e.g., cTLS). For reference, the current charter is available 
> here: 
> 
>   https://datatracker.ietf.org/doc/charter-ietf-tls/
> 
> A draft of the new charter is below, and also available on GitHub [1]. Please 
> have a look and and send comments, either here on the mailing list or in the 
> GitHub repo, by 2359 UTC on 30 January 2020. Any and all feedback is welcome! 
> We would like to complete this in advance of IETF 107 so we can move forward 
> with items such as cTLS. 
> 
> ~~~
> The TLS (Transport Layer Security) working group was established in 1996 to 
> standardize a 'transport layer' security protocol. The basis for the work was 
> SSL (Secure Socket Layer) v3.0 [RFC6101]. The TLS working group has completed 
> a series of specifications that describe the TLS protocol v1.0 [RFC2246], 
> v1.1 [RFC4346], v1.2 [RFC5346], and v1.3 [RFC8446], and DTLS (Datagram TLS) 
> v1.0 [RFC4347], v1.2 [RFC6347], and v1.3 [draft-ietf-tls-dtls13], as well as 
> extensions to the protocols and ciphersuites.
> 
> The working group aims to achieve three goals. First, improve the 
> applicability and suitability of the TLS family of protocols for use in 
> emerging protocols and use cases. This includes extensions or changes that 
> help protocols better use TLS as an authenticated key exchange protocol, or 
> extensions that help protocols better leverage TLS security properties, such 
> as Exported Authenticators. Extensions that focus specifically on protocol 
> extensibility are also in scope. This goal also includes protocol changes 
> that reduce the size of TLS without affecting security. Extensions that help 
> reduce TLS handshake size meet this criteria. 
> 
> The second working group goal is to improve security, privacy, and 
> deployability. This includes, for example, Delegated Credentials, Encrypted 
> SNI, and GREASE. Security and privacy goals will place emphasis on the 
> following:
> 
> - Encrypt the ClientHello SNI (Server Name Indication) and other 
> application-sensitive extensions, such as ALPN (Application-Layer Protocol 
> Negotiation).
> - Identify and mitigate other (long-term) user tracking or fingerprinting 
> vectors enabled by TLS deployments and implementations.
> 
> The third goal is to maintain current and previous version of the (D)TLS 
> protocol as well as to specify general best practices for use of (D)TLS, 
> extensions to (D)TLS, and cipher suites. This includes recommendations as to 
> when a particular version should be deprecated. Changes or additions to older 
> versions of (D)TLS whether via extensions or ciphersuites are discouraged and 
> require significant justification to be taken on as work items.
> 
> With these goals in mind, the working group will also place a priority in 
> minimizing gratuitous changes to (D)TLS.
> ~~~
> 
> Best,
> Chris, on behalf of the chairs
> 
> [1] https://github.com/tlswg/wg-materials/blob/master/charter/charter.md
> 
> ___
> 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] Are the AEAD cipher suites a security trade-off win with TLS1.2?

[Benjamin Beurdouche]

Hi all !

> On 16 Mar 2016, at 19:49, Colm MacCárthaigh  wrote:
> 
> On Wed, Mar 16, 2016 at 2:14 PM, Paterson, Kenny  > wrote:
> Much better would be implementing an optional padding feature for the AEAD
> modes. Something like this draft proposes:
> 
> https://tools.ietf.org/html/draft-pironti-tls-length-hiding-02 
> 
> 
> I hadn't seen that! I wonder is there an appetite here for including more 
> robust LH in TLS1.2 in some form? I mean a real one; as in - let’s it get it 
> into servers and browsers sooner than TLS1.3. 

FYI, the experimental length-hiding feature from miTLS described by Alexandre 
earlier implements the draft specification linked by Kenny…

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

Re: [TLS] Separate APIs for 0-RTT

[Benjamin Beurdouche]

Please forgive me for this naive question, but is there a specific incentive 
for using “SHOULD” instead of
“MUST" only enable 0-RTT application data upon explicit opt-in by the 
application...
My fear is that, even with RFC 2119 terminology, 0RTT will likely be the cause 
of many problems in the future
and that being extra careful here is important… :)

Best,
Benjamin

> On Jun 13, 2017, at 6:12 PM, Andrei Popov  wrote:
> 
> Correct, I’m planning a separate API surface for 0-RTT, as OpenSSL did.
> 
> WRT RFC language, perhaps a reasonable compromise would be to say that a TLS 
> implementation SHOULD only enable 0-RTT application data upon explicit opt-in 
> by the application?
> 
> This is more flexible and may involve separate APIs, new off-by-default flags 
> in the existing APIS, whatever else makes sense for a particular TLS 
> implementation…
> 
> Cheers,
> 
> Andrei


signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls