Tony Arcieri wrote:
> On Wed, Jul 15, 2015 at 2:39 PM, Dave Garrett
> wrote:
>
>> It's the most used of the rarely used curves.
>
>
> I think all "rarely used curves" should be removed from TLS. Specifically,
> I think it would make sense for TLS to adopt a curve portfolio like this:
>
> - CFRG
Dave Garrett wrote:
> Brian Smith posted an RFE to GitHub a few months ago requesting "A
> mechanism is needed to indicate that a session will not be resumed":
> https://github.com/tlswg/tls13-spec/issues/137
>
> The goal is to provide a simple way for either endpo
On Sun, Jul 19, 2015 at 1:16 PM, Viktor Dukhovni
wrote:
> On Sun, Jul 19, 2015 at 02:56:22PM +0200, Eric Rescorla wrote:
>
> > I'm not seeing a lot of value here. Remember that servers are not
> > required (and have never been required) to do session resumption, but
> > much of the overhead of do
Eric Rescorla wrote:
> On Sun, Jul 19, 2015 at 10:17 PM, Brian Smith
> wrote:
>
>> Maybe I'm misunderstanding, but it looks like the current TLS 1.3 draft
>> actually contains a regression here. It seems like it is no longer possible
>> for the server to indica
Eric Rescorla wrote:
> On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith
> wrote:
>
>> It seems weird that the server can supply a lifetime hint but the client
>> can't, especially in cases like WebRTC where there is no functional
>> difference between the two. But,
On Sat, Sep 12, 2015 at 1:49 PM, Eric Rescorla wrote:
> Issue: https://github.com/tlswg/tls13-spec/issues/242
>
> In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues:
>
> "Nobody must ever be *required* to send an alert. Any requirement for
> sending an ale
On Tue, Sep 15, 2015 at 6:00 PM, Joseph Salowey wrote:
> There has been some discussion to remove anonymous DH as described in
> https://www.ietf.org/mail-archive/web/tls/current/msg17481.html. I think
> ekr's message sums up the pros and cons well. I don't think we have
> consensus on this iss
On Wed, Sep 16, 2015 at 2:05 PM, Eric Rescorla wrote:
> In addition, they are already part of TLS, so the question would be if we
> have
> consensus to remove them
>
This thread is about the removal of DH_anon_*, not about raw public keys.
Cheers,
Brian
Hubert Kario wrote:
> On Wednesday 16 September 2015 12:53:53 Brian Smith wrote:
> > Thus, the empirical evidence from Mozilla's
> > widely-deployed implementation shows that (a) the requirement to send
> > alerts is difficult to conform to, and (b) it is unimporta
On Thu, Sep 17, 2015 at 1:50 PM, Nico Williams
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 from looking at the bug databases of
&g
On Thu, Sep 17, 2015 at 2:55 PM, Nico Williams
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 implementations because non-conformant
> >
On Thu, Sep 17, 2015 at 3:00 PM, Nico Williams
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 Smith argues:
> >
> > &
Martin Thomson wrote:
> On 17 September 2015 at 14:46, Brian Smith wrote:
> > Browser vendors, if web servers were to stop sending alerts during
> handshake
> > failures, would you start doing version fallback when a connection is
> > closed?
>
> I'm not sur
On Thu, Sep 17, 2015 at 3:15 PM, Dave Garrett
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 in the security of any
>
On Thu, Sep 17, 2015 at 3:44 PM, Dave Garrett
wrote:
> The client initially has no way of telling apart a conformant TLS 1.3
> server, a TLS 1.2 server, a TLS 1.0 server full of bugs, or a potato.
>
Right. I am not saying anything about how to *receive* alerts. That's a
separate topic.
What I'm
On Thu, Sep 17, 2015 at 4:15 PM, Dave Garrett
wrote:
> On Thursday, September 17, 2015 06:58:19 pm Martin Rex wrote:
> > If one of the communication peers closes the network connection
> > prior to completion of the TLS handshake, then the result is a 100%
> > interoperability failure. How is a
On Fri, Sep 18, 2015 at 4:36 AM, Hubert Kario wrote:
> On Friday 18 September 2015 00:58:19 Martin Rex wrote:
> > Easier troubleshooting is IMO a sufficient rationale to justify
> > existence of the alert mechanism and a "SHOULD send the alert before
> > closing the network connection".
> >
> > A
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 paper stating that b
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 be
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.
>
> https://github.com/tlswg/tls13-spec
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 algorithm)
> are themselves neg
On Fri, Oct 16, 2015 at 10:04 AM, Martin Thomson
wrote:
> On 16 October 2015 at 12:22, Brian Smith wrote:
> > Why only protect TLS 1.3 from such a downgrade? I think it is worthwhile
> to
> > protect TLS 1.2 from the downgrade too, in a similar way. Or, is there
> > some
On Fri, Oct 16, 2015 at 12:12 PM, Martin Thomson
wrote:
> On 16 October 2015 at 13:39, Brian Smith wrote:
> > That would be especially true for an implementation that does False Start
> > for TLS 1.2.
>
> I don't see how false start plays into this. We could have cl
Watson Ladd wrote:
> For these results a
> sender of 2^60 messages can tolerate 2^60 forgery attempts while the
> probability of forgery is at most 1.002/2^52.
TLS only allows one forgery attempt per connection (thus per key). That is,
as soon as a TLS implementation fails to verify a record's
Adam Langley wrote:
> The major change in this version is that the nonce is constructed
> using the scheme that's currently in TLS 1.3.
>
Would it be possible to do something similar for the additional data, so
that there is no additional data in TLS 1.2, just like in TLS 1.3 for
application_dat
Brian Smith 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 avoids
> renegotiation c
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 state for
> more
> >> than 180 days?
> >>
>
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 from the Iwata-Ohashai-Mi
Martin Thomson wrote:
> Whatever the actual limits are, I think that implementatios should be
> encouraged to rekey more strongly.
>
Why?
> And suggesting a stupidly high limit (e.g., ChaCha being
> greater than 2^96) leaves people thinking that they can skip
> implementation and testing of th
Eric Rescorla wrote:
>
> I believe Watson provided one a while back at:
> https://www.ietf.org/mail-archive/web/tls/current/msg18240.html
>
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 imp
Watson Ladd wrote:
> Brian Smith 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 the bounds by 2^17. Note that 3 out of 4 of the au
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 instead of HKDF-SHA512, and then
rename the ChaCha20-Poly1305 cipher suites to _SHA512. Or, use SHA-384.
It seem
On Fri, Dec 18, 2015 at 11:29 AM, Brian Smith 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 instead of HKDF-SHA512, and
Adam Langley wrote:
> On Fri, Dec 18, 2015 at 1:43 PM, Brian Smith 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 since you mention HKDF?
No, I mean for all versions of TLS.
&g
Eric Rescorla wrote:
> On Sun, Dec 20, 2015 at 5:13 PM, Brian Smith wrote:
>
>> Adam Langley wrote:
>>
>>> On Fri, Dec 18, 2015 at 1:43 PM, Brian Smith
>>> wrote:
>>> > That is, it seems it would be better to use HKDF-SHA512 instead of
>>&
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 1.2 PRF and that
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
and
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 draft-irtf-cfrg-curves and I thi
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
> the byte strings opaquely
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 checks will be vulnerable,
> > while fixing protoco
Martin Thomson wrote:
> On 23 December 2015 at 10:23, Brian Smith 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 doesn't
> > really require contributory behavior (thou
Adam Langley wrote:
> On Tue, Dec 22, 2015 at 3:15 PM, Brian Smith wrote:
> > I still think there is value in requiring senders to send their public
> value
> > in the "normalized" form and for allowing (if not requiring) receivers to
> > reject, at least, pub
On Tue, Dec 22, 2015 at 2:09 PM, Brian Smith 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 would implementing
> the
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
rekeying (the new keys are indepen
Kurt Roeckx wrote:
> On Tue, Dec 29, 2015 at 09:02:25AM -1000, Brian Smith wrote:
> >
> > Does that matter, though? The CFRG document doesn't allow the sender to
> set
> > the high bit to 1, right? In particular, it says "All calculations are
> > perf
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 think that is entirely reasonable. TLS 1.2 relies on con
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.
>
> Would it make
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 spec
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 (non-)problem of "omittable
check
Adam Langley wrote:
> On Wed, Dec 30, 2015 at 4:03 PM, Brian Smith 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 prescribe it as the
> solution
> > for this particular problem bec
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 certs. I agree with Y
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 9 values with the prune
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 interoperability with TLS 1.2's NSA
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 element in the SHA-
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 feedback on it
before or after the
Joseph Salowey wrote:
> We seem to have good consensus on moving to RSA-PSS and away from PKCS-1.5
> in TLS 1.3. However, there is a problem that it may take some hardware
> implementations some time to move to RSA-PSS. After an off list discussion
> with a few folks here is a proposal for movi
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
th
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
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 Ciphe
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 time
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 with
> tickets, the s
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
> the user of what we
Dmitry Khovratovich wrote:
> It allows cheap and memoryless verification by the server even though the
> puzzle solving guaranteely requires dozens of MB of RAM from a client
I feel like this is impractical simply because lots of people are
building HTTPS clients that don't even have dozens of MB
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 something impossible
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 same behaviour), "e/"
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 output.
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 signing and is claimed
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 v1.5 because it
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
> of slice-and-dic
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 connection-specific). This chan
Hubert Kario wrote:
> Currently the description of the extension states that only TLS versions
> can
> be listed in the extension and all unknown versions must be ignored.
>
> I wonder if making it explicit that {3, 0} and any lower values MUST NOT be
> advertised wouldn't be a good idea, if only
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/
___
TLS
Eric Rescorla wrote:
> Brian Smith wrote:
>
>> Ilari Liusvaara wrote:
>>
>>> Omitting TLS 1.2 causes failures in some downnegotiation cases (when
>>> there
>>> are higher versions supported, but not overlapping).
>>>
>>
>> Could
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 case
where legacy_version < 1.2 and supported_ver
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
> be sure when w
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 think it just didn't occ
Martin Thomson wrote:
> On 8 November 2016 at 14:01, Brian Smith 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 means an active MitM can use
> this
> > to transport up to 2
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.
>
> This does have a cost
Ilari Liusvaara wrote:
>> The text above indicates the salt length for TLS messages. There are no
>> restrictions placed on certificate signature salt lengths. Does this mean
>> that
>> any valid salt length (from 0 to the maximum permitted) must be supported?
>
> Well, the code I have written en
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 size such as 1M
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 to identify specific ti
David Benjamin wrote:
> draft-ietf-tls-rfc4492bis-15, section 5.11, contains the following text:
>
>Since there are some implementation of the X25519 function that
>impose this restriction on their input and others that don't,
>implementations of X25519 in TLS SHOULD reject public keys
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
> OCSP in the BRs (another example: https://
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 valuable
> troubleshooting information
84 matches
Mail list logo
