Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

Carrick Bartle wrote: > I think the blanket prohibition of reuse of ECDHE keys is maybe not > really justified. > > Why is that? > PFS isn't all-or-nothing. I do think each key should be used when practical, although I don't know why it would be bad to reuse a key for a very short period of

Re: [TLS] [EXTERNAL] Re: Regarding draft-bartle-tls-deprecate-ffdhe

Andrei Popov wrote: > Hi Brian, > > > >- Look at Windows Server 2012 and similar legacy products that are in >widespread use, which don't support any PFS cipher suites except FFDHE. > > Windows Server 2012/Windows 8 support both TLS_ECDHE_ECDSA and > TLS_ECDHE_RSA cipher suites: TLS

Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

Brian Smith wrote: > It is sad that nobody is willing to discuss the obvious downsides of this > proposal as written, which should at least be mentioned in the security > considerations. Without discussing the downsides we're reducing engineering > to politics. If we discuss t

Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

It is sad that nobody is willing to discuss the obvious downsides of this proposal as written, which should at least be mentioned in the security considerations. Without discussing the downsides we're reducing engineering to politics. If we discuss the downsides then we can substantially improve

Re: [TLS] AD Review of draft-ietf-tls-tls13

Kathleen Moriarty wrote: > 4. Section 6.2 Error Alerts > > In addition to sending the error, I don't see any mention of the error > being logged on the server side, shouldn't that be specified? Logging > errors (at least in debug modes when needed) provides

Re: [TLS] comments on draft-ietf-tls-tls13-19

Ryan Sleevi wrote: > On Sat, Apr 22, 2017 at 5:42 PM, Kurt Roeckx wrote: >> >> So for OCSP of a subordinate CAs there doesn't seem to be any >> requirement for a nextUpdate. >> > > Correct. This is part of the many asynchronicities related to CRLs and >

Re: [TLS] Comments on the session ticket format in TLS 1.3

Ivan Ristic wrote: > - The opaque nature of this field also makes connection auditing more > difficult. This is intentional. > For example, I'd like to know if session tickets are used to > resume for a particular connection. Perhaps more importantly, it would be > useful

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).

Aaron Zauner wrote: > I'm not sure that text on key-usage limits in blocks in a spec > that fundamentally deals in records is less confusing, quite > the opposite (at least to me). 1. Consider an implementation that negotiates with another implementation to use a very large record

Re: [TLS] Requiring that (EC)DHE public values be fresh

Adam Langley wrote: > Since this defeats forward security, and is clearly something that > implementations of previous versions have done, this change > specifically calls it out as a MUST NOT. Implementations would then be > free to detect and reject violations of this.

Re: [TLS] (strict) decoding of legacy_record_version?

Martin Thomson <martin.thom...@gmail.com> wrote: > On 8 November 2016 at 14:01, Brian Smith <br...@briansmith.org> wrote: > > Since this field isn't included in the additional_data of the AEAD in TLS > > 1.3 any more, it isn't authenticated. That m

Re: [TLS] (strict) decoding of legacy_record_version?

David Benjamin wrote: > Once you've gotten as far as to switch to TLSCiphertext, I don't see a > reason not to enforce. Keying on versions is problematic (which is why we > avoided a transition to enforcement), but keying on whether the record is > encrypted seems fine. I

Re: [TLS] supported_versions question

Kurt Roeckx wrote: > So I guess you're also saying that a server that implements TLS > 1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should > ignore the supported_versions even when it knows about it? > > I guess I have same questions but with only TLS 1.3 disabled, to

Re: [TLS] supported_versions question

David Benjamin wrote: > Ilari Liusvaara wrote: > >> The case where legacy_version < TLS1.2 IIRC isn't specified, but >> ignoring legacy_version is reasonable in this case too. >> > I imagine that there will be three common implementations for the

Re: [TLS] Supported Versions extension

Eric Rescorla <e...@rtfm.com> wrote: > Brian Smith <br...@briansmith.org> wrote: > >> Ilari Liusvaara <ilariliusva...@welho.com> wrote: >> >>> Omitting TLS 1.2 causes failures in some downnegotiation cases (when >>> there >>> are h

Re: [TLS] Supported Versions extension

Ilari Liusvaara wrote: > Omitting TLS 1.2 causes failures in some downnegotiation cases (when there > are higher versions supported, but not overlapping). > Could you provide a concrete example, please? Thanks, Brian -- https://briansmith.org/

Re: [TLS] Proposed Change to Certificate message (#654)

Nick Sullivan wrote: > PR: https://github.com/tlswg/tls13-spec/pull/654 > > This change adds a set of extensions to the Certificate message. With this > change, the Certificate message can now hold all extension messages that > are certificate-specific (rather than

Re: [TLS] Issue 555: Generate IVs in one HKDF invocation?

Eric Rescorla wrote: > Issue: > https://github.com/tlswg/tls13-spec/issues/555 > > ADL suggested that we could slightly reduce the number of HKDF > computations by generating the IVs as a single block rather than > with individual HKDF-Expands. You can't generally do this kind >

Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA

Martin Rex wrote: > The urban myth about the advantages of the RSA-PSS signature scheme > over PKCS#1 v1.5 keep coming up. PKCS#1 v1.5 is a partial-domain scheme, not a full-domain scheme. So, RSA-PSS (without a salt, or with a fixed salt) might still have an advantage over PKCS#1

Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA

Rene Struik wrote: > The papers [1] and [2] may be of interest here. In [2], Section 3.3, Alfred > Menezes and Neil Koblitz compare FDH-hash RSA signatures, PSS (lots of > randomness in the salt), and a scheme by Wang and Katz that only contains > one bit of randomness with

[TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA

The current draft says "It is RECOMMENDED that implementations implement 'deterministic ECDSA' as specified in [RFC6979]." The current draft also says, regarding RSA-PSS signatures: "When used in signed TLS handshake messages, the length of the salt MUST be equal to the length of the digest

Re: [TLS] Client Hello size intolerance Was: Re: Thoughts on Version Intolerance

Hubert Kario wrote: > 170 were detected as TLS 1.3 incompatible (3.9%) > 183 were detected as TLS 1.4 incompatible (4.2%) > 229 were detected as TLS 1.253 incompatible (5.22%) > > in the below excerpt (full list below, this is just entries that have at least > 4 servers with

Re: [TLS] Thoughts on Version Intolerance

Hubert Kario wrote: > I'm quite sure that if I were sending a huge extension or many big extensions, > the percentage of servers that are incompatible to them would be similar, if > not worse. A relatively small 3KiB client hello already causes issues and this > is not exactly

Re: [TLS] Fwd: I-D Action: draft-lemon-tls-blocking-alert-00.txt

On Mon, Jun 6, 2016 at 7:21 AM, Ted Lemon wrote: > I've posted a new document to the datatracker that adds some TLS alert > codes that can be sent to indicate that a particular TLS request has been > blocked by the network. This attempts to address the problem of notifying >

Re: [TLS] Limiting replay time frame of 0-RTT data

On Fri, Mar 11, 2016 at 10:21 AM, Kyle Nekritz wrote: > Note: it’s also useful for the server to know which edge cluster the early > data was intended for, however this is already possible in the current > draft. In ECDHE 0-RTT server configs can be segmented by cluster, and

Re: [TLS] JPAKE

Robert Cragie wrote: > I was told it wouldn't receive much interest because it is based on TLS > 1.2 and the current focus is very much on 1.3. The aim is to get an > informational RFC out shortly. > I'm looking forward to the RFC and I would be happy to offer

Re: [TLS] Require deterministic ECDSA

Joseph Birr-Pixton wrote: > I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA. > What about the way BoringSSL (and OpenSSL, I think) does it? It incorporates all the inputs that RFC6979 does, but using SHA-512 instead of HMAC. And, it also includes a random

Re: [TLS] Simplifying signature algorithm negotiation

David Benjamin wrote: > 4. Deprecate ecdsa_sha256, etc., in favor of new > ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_* > values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although this > introduces new premultiplications, it’s only

Re: [TLS] Simplifying signature algorithm negotiation

David Benjamin wrote: > (Whether such certificates exist on the web is probably answerable via CT > logs, but I haven't checked.) > Me neither, and I think that's the key thing that would need to be checked to see if my suggestion is viable. 3. You get better

Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

Simon Josefsson wrote: > Allocating a code point for X25519 could be done and is long overdue > (first draft September 2013). X448 is also stable. Code points for > Ed25519 and Ed448 is more problematic since TLS authentication has > historically had interaction with PKIX

Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

Adam Langley <a...@imperialviolet.org> wrote: > On Wed, Dec 30, 2015 at 4:03 PM, Brian Smith <br...@briansmith.org> wrote: > > > I think it is a good idea to implement the session hash extension, in > > general. However, I think it is a bad idea to

Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

Martin Thomson wrote: > On 30 December 2015 at 22:16, Ilari Liusvaara > wrote: > >> Would it make sense to have session hash as a requirement in TLS > >> 1.2 when you want to use Curve25519? > > > > I don't think that is reasonable. > > I

Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

Kurt Roeckx wrote: > On Tue, Dec 29, 2015 at 10:10:47PM +0200, Karthikeyan Bhargavan wrote: > > As mentioned before, validating Curve25519 public values is necessary in > TLS 1.2 without session hash. > > Otherwise, as we pointed out in [1], the triple handshake attack returns. >

[TLS] draft-ietf-tls-curve25519: Remove Appendix A

I suggest that the entire Appendix A be removed, as it duplicates draft-irtf-cfrg-curves-11 and it is too difficult and tedious to verify that it matches what draft-irtf-cfrg-curves-11 says. Also, it doesn't say anything about X448. I've noticed that the draft has a few other places that talk

Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

Watson Ladd wrote: > Why not hash the public values into the result of the key exchange? I > don't want security to depend on omittable checks. > One would need an omittable check in the code to decide whether to do that extra hashing, so that wouldn't solve the

Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

On Tue, Dec 22, 2015 at 2:09 PM, Brian Smith <br...@briansmith.org> wrote: > If an implementation only implements ECDHE cipher suites then > implementing the session hash extension is not necessary, according to RFC > 7627. I believe there are also a few other factors that wou

Re: [TLS] Data volume limits

Ilari Liusvaara wrote: > OTOH, you can't drop an attacker knowing older key without doing > new key exchange. > I think it would be very unfortunate to have the complexity of key update (the new keys are derived from the old keys) without having the benefits of

[TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

The current draft [1] says: Other than this recommended check, implementations do not need to ensure that the public keys they receive are legitimate: this is not necessary for security with Curve25519. However, Thai Duong (of BEAST fame, among other things) wrote that TLS 1.2

Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

Martin Thomson wrote: > Watson Ladd wrote: > > Textbook DH does not ensure contributory behavior. Applications don't > > implement the required checks for poorly designed protocols. If we insert > > checks, applications which fail to make those

Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

Martin Thomson <martin.thom...@gmail.com> wrote: > On 23 December 2015 at 10:23, Brian Smith <br...@briansmith.org> wrote: > > It may be the case that TLS requires contributory behavior and point > > validation is still unnecessary. Or, it may be the case that TLS

Re: [TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit.

On Tue, Dec 22, 2015 at 11:59 AM, Adam Langley wrote: > You're correct, but I'm trying to say that the CFRG document defines a > function that operates on bytestrings so that higher-level protocols > don't have to worry about things like this. I think TLS should handle >

Re: [TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit.

Adam Langley wrote: > Currently > https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3 > says that implementations SHOULD reject inputs with the high-bit set. > I think that should be dropped. The X25519 function is specified in > terms of bytes in

Re: [TLS] PRF digest function for ChaCha20-Poly1305 cipher suites

Eric Rescorla wrote: > Sorry, I'm still confused TLS 1.2 uses a specific PRF. TLS 1.3 uses HKDF. > Are you suggesting TLS 1.2 use the TLS 1.2 PRF with SHA-512 and that > TLS 1.2 use SHA-512 with HKDF, or something different? > I mean that TLS 1.2 should use SHA-512 with the TLS

Re: [TLS] PRF digest function for ChaCha20-Poly1305 cipher suites

Adam Langley <a...@imperialviolet.org> wrote: > On Fri, Dec 18, 2015 at 1:43 PM, Brian Smith <br...@briansmith.org> wrote: > > That is, it seems it would be better to use HKDF-SHA512 instead of > > **HKDF-SHA256**. > > I assume that you mean for TLS 1.3 sin

Re: [TLS] PRF digest function for ChaCha20-Poly1305 cipher suites

Eric Rescorla <e...@rtfm.com> wrote: > On Sun, Dec 20, 2015 at 5:13 PM, Brian Smith <br...@briansmith.org> wrote: > >> Adam Langley <a...@imperialviolet.org> wrote: >> >>> On Fri, Dec 18, 2015 at 1:43 PM, Brian Smith <br...@briansmith.org> &g

Re: [TLS] PRF digest function for ChaCha20-Poly1305 cipher suites

On Fri, Dec 18, 2015 at 11:29 AM, Brian Smith <br...@briansmith.org> wrote: > Hi, > > The recent renaming of the ChaCha20-Poly1305 cipher suites brought > something to my attention that I hadn't thought about before. It seems > like it might be better to use HKDF-SHA512 i

Re: [TLS] Data volume limits

Watson Ladd <watsonbl...@gmail.com> wrote: > Brian Smith <br...@briansmith.org> wrote: > > So, if [2] is correct, then we can take Watson's 2^36 and multiply it by > > 2^17 to get 2^53 bytes as the limit? It seems so, since [2] claims that > > they've improved th

Re: [TLS] Data volume limits

Watson Ladd wrote: > The issue is the bounds in Iwata-Ohashai-Minematsu's paper, which show > a quadratic confidentiality loss after a total volume sent. This is an > exploitable issue. > Please explain in more detail how you got "2^36 bytes" for a nonce size of 96 bits

Re: [TLS] The progress about theNegotiated FFDHE proposal

On Wed, Dec 9, 2015 at 8:44 AM, Sean Turner wrote: > On Dec 05, 2015, at 10:43, Ilari Liusvaara > wrote: > > > > On Sat, Dec 05, 2015 at 11:32:40PM +0800, Xuelei Fan wrote: > >> Hi, > >> > >> Any one know why the negotiated FFDHE draft hang on MISSREF

Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-01.txt

Brian Smith <br...@briansmith.org> wrote: > This way, one Poly1305 invocation per record could be saved, potentially, > forapplication_data records, which is the common case. > > This is still true, but... > An implementation that avavoids sending encrypted alerts and av

Re: [TLS] PR for anti-downgrade mechanism

Karthikeyan Bhargavan wrote: > The attack we’re protecting against is the following: > [snip] > The key observation is that downgrade protection in TLS 1.2 (and below) > relies on the Finished MAC, but the elements that go into computing this > MAC (DH group, hash

Re: [TLS] PR for anti-downgrade mechanism

On Fri, Oct 16, 2015 at 10:04 AM, Martin Thomson <martin.thom...@gmail.com> wrote: > On 16 October 2015 at 12:22, Brian Smith <br...@briansmith.org> wrote: > > Why only protect TLS 1.3 from such a downgrade? I think it is worthwhile > to > > protect TLS 1.2 from t

Re: [TLS] PR for anti-downgrade mechanism

On Fri, Oct 16, 2015 at 12:12 PM, Martin Thomson <martin.thom...@gmail.com> wrote: > On 16 October 2015 at 13:39, Brian Smith <br...@briansmith.org> wrote: > > That would be especially true for an implementation that does False Start > > for TLS 1.2. > >

Re: [TLS] PR for anti-downgrade mechanism

On Fri, Oct 9, 2015 at 2:23 AM, Eric Rescorla wrote: > Please take a look at the following PR which documents a suggestion > made by Karthik Bhargavan about how to prevent protection against > downgrade against downgrade from TLS 1.3 to TLS 1.2 and below. > >

Re: [TLS] Fwd: New Version Notification for draft-whyte-qsh-tls13-01.txt

On Sun, Sep 20, 2015 at 7:59 PM, William Whyte < wwh...@securityinnovation.com> wrote: > Hi all, > > We've updated the TLS 1.3 Quantum Safe Handshake draft to use extensions > as suggested by DKG in Prague. All comments welcome. > > There's an interesting issue here: McEliece keys, which should

Re: [TLS] Key Hierarchy

On Sun, Sep 20, 2015 at 4:58 PM, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/pull/248 > > Aside from some analytic advantages > What are the analytic advantages? Also, a question that applied even to the older design: I remember the an HKDF paper and the HKDF

Re: [TLS] Should we require implementations to send alerts?

On Thu, Sep 17, 2015 at 3:00 PM, Nico Williams <n...@cryptonector.com> wrote: > On Sat, Sep 12, 2015 at 01:49:49PM -0700, Eric Rescorla wrote: > > Issue: https://github.com/tlswg/tls13-spec/issues/242 > > > > In https://github.com/tlswg/tls13-spec/pull/231, Brian Sm

Re: [TLS] Should we require implementations to send alerts?

On Thu, Sep 17, 2015 at 3:15 PM, Dave Garrett <davemgarr...@gmail.com> wrote: > On Thursday, September 17, 2015 06:00:05 pm Brian Smith wrote: > > There's no evidence that the presence or absence of an alert when a > > connection is closed makes any positive difference i

Re: [TLS] Should we require implementations to send alerts?

Martin Thomson <martin.thom...@gmail.com> wrote: > On 17 September 2015 at 14:46, Brian Smith <br...@briansmith.org> wrote: > > Browser vendors, if web servers were to stop sending alerts during > handshake > > failures, would you start doing version fallback w

Re: [TLS] Should we require implementations to send alerts?

On Thu, Sep 17, 2015 at 1:50 PM, Nico Williams <n...@cryptonector.com> wrote: > On Wed, Sep 16, 2015 at 12:53:53PM -0700, Brian Smith wrote: > > Further, the alerting mechanism has encouraged the unsafe practice of > > "version fallback." It is clear fr

Re: [TLS] Should we require implementations to send alerts?

On Thu, Sep 17, 2015 at 2:55 PM, Nico Williams <n...@cryptonector.com> wrote: > On Thu, Sep 17, 2015 at 05:47:50PM -0400, Dave Garrett wrote: > > On Thursday, September 17, 2015 03:27:10 pm Brian Smith wrote: > > > (We should focus on conformant implementation