On Mon, Jul 13, 2015 at 04:11:04AM +, Andrei Popov wrote:
> I'm not happy with this either. The spec already says:
>
> "If the client supports only the default hash and signature algorithms
>(listed in this section), it MAY omit the signature_algorithms
>extension. If the client do
On Mon, Jul 13, 2015 at 04:30:06PM +0200, Martin Rex wrote:
> Section 7.4.1.4 Hello Extensions and its subsections are clearly IRRELEVANT
> for a client that does not use Hello Extensions.
Let's not go back to lawyering the RFCs. We've been there already,
with not much success. I think we can r
On Mon, Jul 13, 2015 at 05:11:29PM +, Andrei Popov wrote:
> I think a good design is to have the client explicitly advertise any
> algorithms the client is willing/able to support, and for the server to
> honor the client's capabilities.
To the extent possible. However, the server SHOULD NOT
On Mon, Jul 13, 2015 at 07:45:30PM +, Andrei Popov wrote:
> Would it make sense for an opportunistic client to advertise all algorithms
> commonly supported in the server certs? After all, there are relatively
> few signature/hash pairs in use, and they are changing very slowly over
> time.
T
On Mon, Jul 13, 2015 at 10:31:16PM +, Andrei Popov wrote:
> When old algorithms are deprecated and new algorithms replace them in
> actual deployments (a very slow process), an opportunistic client would
> need to be updated, just like a normal server-authenticating client does.
> Except for t
On Tue, Jul 14, 2015 at 12:38:51AM -0400, Dave Garrett wrote:
> > Furthermore, DANE-EE(3) clients and certificate pinning clients
> > cannot use anon_DH, they still a recognizable certificate from the
> > server, they just often don't need a recognizable signature. Even
> > DANE-TA(2) clients mig
On Tue, Jul 14, 2015 at 11:31:26AM +0200, Hubert Kario wrote:
> >
> > All certificates provided by the server SHOULD be signed by a
> > hash/signature algorithm pair indicated by the client's
> > "signature_algorithms" extension (or the defaults assumed in
On Tue, Jul 14, 2015 at 03:46:12PM +0200, Martin Rex wrote:
[ There's no need to belabour the obvious, yes unauthenticated TLS
does not protect against active attacks, absent authenticated
channel binding post handshake. This does not mean that the are
no appropriate use-cases for anon_DH a
On Tue, Jul 14, 2015 at 07:30:38PM +, Andrei Popov wrote:
> Using anonymous cipher suites for opportunistic connections allows the
> server operator to explicitly enable anonymous connections, and it saves
> bytes on the wire.
Yes, and informs the server that the client is skipping authentica
On Tue, Jul 14, 2015 at 08:06:19PM +, Andrei Popov wrote:
> If opportunistic TLS handshakes need to be indistinguishable from
> server-authenticated TLS handshakes, then perhaps opportunistic clients
> have no choice but to send the signature_algorithms extension (when offering
> TLS1.2). The
On Tue, Jul 14, 2015 at 01:49:36PM -0700, Martin Thomson wrote:
> On 14 July 2015 at 13:08, Viktor Dukhovni wrote:
> > Yes, and informs the server that the client is skipping authentication,
> > which is often useful information on the server end.
>
> The problem here is
On Wed, Jul 15, 2015 at 01:59:26PM -0700, Adam Langley wrote:
> On Wed, Jul 15, 2015 at 1:58 PM, Deirdre Connolly
> wrote:
> >
> >> So, should it stay or should it go now? Opinions?
> >
> > +1 that sect571r1 be removed.
>
> I also believe that it should be removed.
Same here, I think in this ca
On Wed, Jul 15, 2015 at 11:41:03PM -0400, Jeffrey Walton wrote:
> > Same here, I think in this case "less is more". There is no
> > compelling reason for this curve, and needless diversity here is
> > counter-productive.
>
> It provides 256-bits of security. Its the only curve I am aware that
> c
On Wed, Jul 15, 2015 at 11:52:13PM -0400, Jeffrey Walton wrote:
> > An auditor who believes that we can rigourously quantify the security
> > of these curves precisely enough to say which is stronger or more
> > closely "matches" AES-256, should be laughed out of the room and fired.
>
> Maybe so,
On Thu, Jul 16, 2015 at 12:17:28AM -0400, Dave Garrett wrote:
> Side question: what is the meaning of the "r" in the naming convention we
> use? (e.g. secp521r1, & sect571r1 vs. sect571k1)
The "r" means that a mysterious seed can be used to "verify" that
the curve paramets are ("nothing up my sle
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 doing it (having to have a database, session
> ticket machinery) is a
On Sun, Jul 19, 2015 at 08:18:18PM +0200, Daniel Kahn Gillmor wrote:
> On Wed 2015-07-01 05:58:20 +0200, Viktor Dukhovni wrote:
> > Instead, there would need to be in various cases:
> >
> > * A validated chain of CNAMEs (possibly synthesized via validated
> >
On Sun, Jul 19, 2015 at 04:40:15PM -0400, Brian Smith wrote:
> Here's the part that is not is still not
> clear to me: Is the SessionTicket extension still to be used or not?
While we now have
https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.4
In TLS 1.2 and below, this
On Sun, Jul 19, 2015 at 04:58:02PM -0400, Dave Garrett wrote:
> This draft spec explicitly obsoletes RFC 5077. (listed up top)
> https://tools.ietf.org/html/rfc5077#section-3.2
However, part of RFC 5077 remains applicable:
https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.3.11
On Sun, Jul 19, 2015 at 11:10:42PM +0200, Eric Rescorla wrote:
> > So indeed it is no longer possible for the client to signal the
> > ability/desire to resume sessions, and servers will generate session
> > tickets absent any indication that the client intends to use them.
> >
> > This does not i
On Sun, Jul 19, 2015 at 05:28:27PM -0400, Brian Smith wrote:
> Thus, because of that
> possibility, it is valuable to have the client be able to say "don't cache
> the session" and/or limit the session's lifetime, so the client can help
> direct the level of forward secrecy for the session. Right
On Wed, Jul 22, 2015 at 07:45:17AM -0400, Paul Wouters wrote:
> I think the server should stick to one chain, from the root to itself,
> so it does not have to deal with variable chain blobs per client.
> That will allow server code to stick to something like hourly
> regenerating the blob for use
On Wed, Jul 22, 2015 at 05:23:39PM -0400, Paul Wouters wrote:
> >Should everything other than the first CNAME be in additional
> >records?
>
> I think so.
>
> > Should all the above (with their RRSIGs) be in the answer
> >section, with the union of the supporting DNSKEY/RRSIG/DS records
> >as ad
On Thu, Jul 23, 2015 at 11:43:45AM -0400, Dave Garrett wrote:
> Right now, the restrictions section prohibits:
> RC4, SSL2/3, & EXPORT/NULL entirely (via min bits)
> and has "SHOULD" use TLS 1.3+ compatible with TLS 1.2, if available
So much for using NULL ciphers for client-server authentication
On Fri, Jul 24, 2015 at 02:03:13PM -0400, Dave Garrett wrote:
> > and how a server can tell that the client is TLS1.3 only and not
> > TLS1.0-up-to-
> > TLS1.3?
>
> TLS 1.0-1.3 shouldn't be offering export ciphers any more than TLS 1.3
> only. A TLS 1.0-1.2 client, or at least one offering that,
On Sat, Jul 25, 2015 at 06:54:36AM +, Salz, Rich wrote:
> > What we've cannot yet turn off is RC4.
>
> Then do not use TLS 1.3
Actually, we can use TLS 1.3, just not with peers that only do RC4.
Provided the 1.3 servers don't do anything actively hostile and
terminate the handshake when they
On Sat, Jul 25, 2015 at 07:01:42PM +0200, Martin Thomson wrote:
> On 25 July 2015 at 17:48, Salz, Rich wrote:
> > "we" meaning browsers. "we" not being everyone who will use TLS 1.3
> >
> > Ekr has pointed out a problem; if you connect with a protocol range and
> > proffer RC4, can we do anythi
On Sat, Jul 25, 2015 at 02:53:17PM -0400, Dave Garrett wrote:
> 3) Just to state the obvious: If a client is going to do PSK resumption
> with a non-PFS suite, it needs to offer a non-PFS suite.
Forward-secrecy is not about doing or not doing DHE/ECDHE those
are just means to an end. Forward-sec
On Sat, Jul 25, 2015 at 03:00:54PM -0400, Dave Garrett wrote:
> On Saturday, July 25, 2015 01:18:49 pm Viktor Dukhovni wrote:
> > I would go further, and say that "prohibiting RC4" in any sense
> > that is more than prohibiting its use as the final outcome of a
> &
On Tue, Jul 28, 2015 at 05:41:58PM +0200, Hubert Kario wrote:
> I see one possible problem with TLS1.3 not being a superset of TLS1.2.
>
> Consider the following:
> Server which supports TLSv1.3 but is configured to accept only AES256
> ciphers.
>
> Client which advertises TLSv1.3, but no suppor
On Tue, Jul 28, 2015 at 09:44:34PM -0400, Shumon Huque wrote:
> For the following hypothetical example:
>
> _443._tcp.www.example.com. IN CNAMEca.example.net.
> ca.example.net. IN TLSA 2 0 1
This is simpler than the general case, everything is still "linear",
because
On Tue, Jul 28, 2015 at 10:43:29PM -0400, Shumon Huque wrote:
> > This is no longer the DNS response to a single query (iterative
> > resolvers generally chase CNAMEs), since one first CNAME expands
> > the original target hostname to obtain the TLSA base domain (provided
> > the CNAME chain is va
On Mon, Aug 17, 2015 at 12:38:54PM +, Peter Gutmann wrote:
> One thing that I'd really like to know is that given the non-PFS (EC)DH suites
> were obviously a dumb idea and barely supported by anything (not just in terms
> of TLS code, no public CA I know of will issue the required X9.42 certs
On Mon, Aug 17, 2015 at 03:18:14PM +, Viktor Dukhovni wrote:
> The relevant code was added to the 1.0.2 dev branch in Apr of 2012,
> backporting said code from the "master" branch where fixed DH
> support was enabled in January of 2012.
>
> On a related note, for wh
On Mon, Aug 17, 2015 at 03:53:59PM +, Peter Gutmann wrote:
> Viktor Dukhovni writes:
>
> >I can't answer why, but I know what and when:
>
> I was trying to avoid finger-pointing so I didn't go through the changelog to
> see whodunnit, I was more interested in
On Mon, Aug 17, 2015 at 06:22:04AM -0400, Yaron Sheffer wrote:
> * Server Configuration: how does the client know to whom the
>configuration applies? For example if I connected to
>"*.example.com" (a wildcard cert) and now I connect to
>"srv.example.com", should I use
On Mon, Aug 24, 2015 at 05:33:18PM -0400, Paul Wouters wrote:
> On Mon, 24 Aug 2015, Eric Rescorla wrote:
>
> >TLS 1.3 encrypts both the client's and server's certificates already.
> >The server's certificate is secure only against passive attack.
>
> Not having read the TLS 1.3 draft, in IKE pa
On Mon, Aug 24, 2015 at 09:56:50PM -0400, Paul Wouters wrote:
> >>Not having read the TLS 1.3 draft, in IKE parties can send a hash of the
> >>CAs they trust, so unless you receive a hash of a known CA to you, you
> >>can withold your own certificate from being sent.
> >>
> >>Is a similar mechanis
On Tue, Aug 25, 2015 at 10:26:24AM -0400, Kyle Rose wrote:
> (I am not claiming anything about the purity of this approach, only
> that it is technically feasible.)
SSH now has ciphersuites where the payload length is encrypted,
IIRC via a key that is different from the payload key.
--
On Wed, Aug 26, 2015 at 02:11:01PM -0700, Joseph Salowey wrote:
> It looks like we have good consensus on PR 169 to relax certificate list
> ordering requirements. I had one question on the revised text. I'm
> unclear on the final clause in this section:
>
> "Because certificate validation requ
On Thu, Aug 27, 2015 at 01:22:33PM -0400, Santosh Chokhani wrote:
> To me it seems that both of these wordings could be interpreted by someone
> that if you do not have a trust anchor and you get it in the TLS handshake,
> you can use it and trust it.
>
> That sounds dangerous.
Beyond a general
On Thu, Aug 27, 2015 at 12:26:03PM -0700, Eric Rescorla wrote:
> My problem is precisely the conflation of offering with negotiating. The
> way that many stacks work (for instance NSS) is that they negotiate the
> cipher suite *first* and then they check for the presence or absence of
> the releva
On Fri, Aug 28, 2015 at 04:27:28PM +0200, Viktor S. Wold Eide wrote:
> > I don't think this matches most TLS use cases very well, since the client
> > generally isn't authenticated at all, so there's no point in the server
> > progressively
> > revealing more.
> >
> >
> Although the client general
On Fri, Aug 28, 2015 at 12:13:03PM -0400, Dave Garrett wrote:
> The idea I had the other day is that we can technically do SNI encryption
> with the current TLS 1.3 draft, as-is. All that needs to really be done
> is stick it in a 0-RTT EncryptedExtensions, preferably only when the server
> specif
On Fri, Aug 28, 2015 at 11:07:02AM -0700, Martin Thomson wrote:
> This seems fine to me, though I'll note that 7250 only really saves
> you space when it comes down to it. You can wrap your raw public key
> in a certificate, just like we do in WebRTC, and then you don't need
> 7250 support in you
On Fri, Aug 28, 2015 at 01:27:57PM -0700, Tony Arcieri wrote:
> On Friday, August 28, 2015, Dang, Quynh wrote:
> >
> > People who don't use DSA, then they don't use DSA. People who use DSA
> > right, it should be fine for them to use DSA.
> >
> Can you name one of these people? If not, you seem t
On Wed, Sep 02, 2015 at 04:39:59PM +0200, Julien ?LIE wrote:
> Since the publication of RFC 7465 "Prohibiting RC4 Cipher Suites", there has
> been a discrepancy with the requirements of Section 5 of RFC 4642 "Using
> Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)":
>
>
On Wed, Sep 02, 2015 at 05:13:08PM +0200, Julien ?LIE wrote:
> >AFAIK, NNTP peering relationships are fairly static, and mandatory
> >TLS seems like the way to go in that case. But if NNTP servers
> >contact other servers "on the fly", then opportunistic TLS may
> >be appropriate and one might ev
On Wed, Sep 02, 2015 at 06:28:13PM -0700, Ben Campbell wrote:
> -- 6:
> I'm not sure I understand the meaning of "permanently assign the early
> code point for the padding extension in its ExtensionType registry".
> Does this mean that an early allocation was done for this? If so, it
> seems lik
On Sat, Sep 12, 2015 at 01:49:49PM -0700, Eric Rescorla wrote:
> "Nobody must ever be *required* to send an alert. Any requirement for
> sending an alert should be SHOULD, at most."
Interoperability problems are hard enough to debug even when alerts
are sent, and they are *very* useful. If the p
On Wed, Sep 16, 2015 at 12:02:57PM +0200, Florian Weimer wrote:
> I'm trying to explain that any requirement to send fatal alerts will be
> difficult to implement. With the BSD sockets API, the only way to do
> that reliable is *not* to close the socket immediately, which is
> apparently not what
On Wed, Sep 16, 2015 at 02:10:36PM -0400, Dave Garrett wrote:
> > Yes. I wouldn't recommend following this path to others; it's not
> > easy and the return on that investment isn't all good. The mess we
> > were attempting to clean up with HTTP/2 was the state of TLS
> > deployment on the web, n
On Wed, Sep 16, 2015 at 03:03:54PM -0400, Dave Garrett wrote:
> The suggestion that started this thread was to have a "Standard TLS Profile"
> that actually allowed EXPORT ciphers & SSL3. So yeah, this proposal feels
> like a suggestion to keep allowance of obsolete junk as the norm with
> "defens
On Wed, Sep 16, 2015 at 02:38:05PM -0700, Eric Rescorla wrote:
> The point I was making was that presently we have:
>
> - Certificates
> - Raw keys
> - Anon
>
> This proposal is to remove Anon, thus making things strictly simpler, since
> Raw keys can replace Anon but not the other way around. O
On Wed, Sep 16, 2015 at 07:14:48PM -0400, Dave Garrett wrote:
> Yeah, we don't need to argue semantics. My point is that I'd agree with
> a more strict profile than what we have now as an addon, but not a more
> permissive profile, as was the initial suggestion.
I don't think that "permissive" vs
On Wed, Sep 16, 2015 at 08:31:41PM -0400, Daniel Kahn Gillmor wrote:
> For those worried about computational cost: the raw public key or
> certificate themselves do not have to be valid mathematical objects if
> the peer is not inclined to check them.
That's not generally possible. Many servers
On Sat, Sep 19, 2015 at 03:14:07PM +0200, Kurt Roeckx wrote:
> But I wonder in which cases it's important to receive the fatal
> alert. I guess it's the cases where it can tell you that
> connecting again might work, and so would only be during the
> handshake. The only case I can think of is so
On Sun, Sep 20, 2015 at 11:02:19AM +0200, Julien ÉLIE wrote:
> Though I've read a few pages explaining how CRIME and BEAST attacks work, I
> still do not see well how TLS-level compression would make NNTP vulnerable.
> Same thing for POP or IMAP I believe.
>
> The news server does not leak inform
On Fri, Sep 25, 2015 at 07:40:05PM +0100, Jeremy Harris wrote:
> Why is it not possible for TLS1.3 to provide that same service
> combination, but implemented by design in a layered fashion?
TLS is correctly agnostic of semantic boundaries, in application
data. For this to work, applications wou
On Sat, Sep 26, 2015 at 12:19:17AM +, Salz, Rich wrote:
> > I wonder if it would have been possible to do this via renegotiation, though
> > this has overhead.
>
> Intriguing, but moot of course, since renegotiation is gone. :) Interesting
> corner-cases to think about: is compression resta
On Fri, Oct 09, 2015 at 02:23:30PM +0200, Eric Rescorla wrote:
> Hi folks,
>
> 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://gi
On Fri, Oct 09, 2015 at 10:23:09PM +0200, Eric Rescorla wrote:
> It's largely arbitrary, but the reasoning is as follows. There are
> apparently some TLS 1.2 servers which randomly generate the entire server
> random (and https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime-00
> would
> enc
On Sat, Oct 10, 2015 at 11:28:28PM +0300, Ilari Liusvaara wrote:
> > To be clear, the only thing that's allowed is SHA-1 in *certificates*.
> > It's forbidden in CertificateVerify.
>
> Isn't using it in certificates precisely more dangeous than using it in
> CertificateVerify (especially with TLS
On Sat, Oct 10, 2015 at 08:59:08PM +, Viktor Dukhovni wrote:
> I don't want to see client's or servers hanging up just because a
> peer presents a SHA-1 chain that would have been simply ignored
> had it been SHA2-256 instead.
In particular pull request 287 breaks opportun
On Sat, Oct 10, 2015 at 05:11:56PM -0400, Dave Garrett wrote:
> Note that opportunistic encryption is weird and getting
> the whole document to be perfect for it might not be entirely doable, as
> OE needs to tolerate more fuzziness than the main spec should allow.
Unfortunately requirements in t
On Sat, Oct 10, 2015 at 06:46:47PM -0400, Dave Garrett wrote:
> > Unfortunately requirements in the base TLS document end up "set in
> > stone" in software implementations, and then break opportunistic
> > TLS in ways application software can't work around.
>
> I do agree with rewording the text
On Sat, Oct 10, 2015 at 11:00:30PM -0400, Dave Garrett wrote:
> On Saturday, October 10, 2015 10:35:16 pm Viktor Dukhovni wrote:
> > This is not difficult, it just requires not forgetting that there's
> > more than one way to do (or not do) authentication, and that the
>
On Sun, Oct 11, 2015 at 12:33:33AM -0400, Dave Garrett wrote:
> https://github.com/tlswg/tls13-spec/pull/287
>
> PR updated with some revisions. Please take a look at some point and tell me
> what you think.
Still problematic, by changing more text than necessary. The following
is wrong and sh
On Sun, Oct 11, 2015 at 02:01:59AM -0400, Dave Garrett wrote:
> On Sunday, October 11, 2015 01:53:34 am Dave Garrett wrote:
> > If the trust model doesn't need the problematic portion of the chain,
> > then the chain is not trustworthy and this does not apply.
>
> Sorry, follow-up to fix a rather
On Sun, Oct 11, 2015 at 01:53:34AM -0400, Dave Garrett wrote:
> On Sunday, October 11, 2015 01:08:41 am Viktor Dukhovni wrote:
> > Is this clear yet?
>
> It's clear, but we disagree on a few points here.
It is important to keep in mind that the TLS protocol specification
h
On Sun, Oct 11, 2015 at 01:24:36PM -0400, Dave Garrett wrote:
> > Is is not appropriate mission for the TLS WG to launch a wider
> > anti-SHA1 crusade. The TLS WG just needs to just avoid SHA-1
> > problems in the TLS protocol itself (PRFs, ...). Avoiding SHA-1
> > in PKIX is outside this group'
> On Oct 11, 2015, at 3:59 PM, Dave Garrett wrote:
>
> On Sunday, October 11, 2015 02:17:17 pm Viktor Dukhovni wrote:
>> Please start with a sensibly minimal proposal that achieves the
>> essential goal of deprecating *trust* in SHA-1. Please do not
>> overreach by
On Sun, Oct 11, 2015 at 07:13:03PM -0400, Dave Garrett wrote:
> A wording change might be helpful here. Instead of no sending of SHA1 certs:
> 1) SHA1 signatures must not be trusted
Excellent.
> 2) servers must not send cert chains they do not trust
Pointless overreach that breaks things.
> Y
On Sat, Oct 17, 2015 at 11:35:35AM -0700, Eric Rescorla wrote:
> Trying to close the loop on this, I think people are generally in favor of
> this
> mechanism, so we just need a concrete construction.
>
> I propose we use an N bit field divided as follows
>
> - N - 8 bits of fixed sentinel.
> -
On Sat, Oct 17, 2015 at 02:16:49PM -0700, Eric Rescorla wrote:
> 3. (Optional) If you have a downgrade, parse the last byte to see the
> server's actual version.
> In any case, abort.
>
> What have I missed?
>From my perspective, there's not much benefit to knowing the actual
version, and an
On Sat, Oct 17, 2015 at 02:53:57PM -0700, Eric Rescorla wrote:
> > It also has a slightly better collision risk, though it's already down
> > quite low
>
> Given that the TCP checksum has a false negative rate far higher than
> 2^{-56} and
> any TCP errors cause TLS handshake failures, this doesn
On Sat, Oct 17, 2015 at 03:10:01PM -0700, Eric Rescorla wrote:
> > This argument is not complete. The false negative rate from TCP
> > is not by itself sufficient to determine the observed error rate.
> > One needs to combine that with the undetected error rate from
> > underlying network to obta
On Sat, Oct 17, 2015 at 03:20:08PM -0700, Eric Rescorla wrote:
> I don't feel strongly about this, but I don't see how what you suggest
> is any simpler than the version number encoding I proposed. Arguably,
> it's more complicated since you can't implement the sentinel check with
> memcmp().
Th
On Wed, Oct 21, 2015 at 12:15:25PM -0700, Martin Thomson wrote:
> The current draft permits the use of SHA-1 in the certificate chain,
> which gives SHA-1 a free pass indefinitely.
Forbidding the sending of SHA-1 chains was wrong last time we
discussed this at length, and remains wrong now.
Whet
On Wed, Oct 21, 2015 at 08:14:19PM -0400, Dave Garrett wrote:
> On Wednesday, October 21, 2015 03:56:09 pm Viktor Dukhovni wrote:
> > Whether SHA-1 in the chain is used to make trust decisions is only
> > known to the client, and the server MUST NOT preempt that by denying
> &
On Thu, Oct 22, 2015 at 08:42:51AM +0100, Rob Stradling wrote:
> IINM this also changes the fallback for servers that choose to include a
> PKIX trust anchor certificate in the Server Certificate message.
The signatures of trust-anchor (i.e. self-signed) certificates MUST
NOT be constrained by th
On Thu, Oct 22, 2015 at 10:30:33AM -0700, Martin Thomson wrote:
> > % a certificate that specifies a trust anchor MAY be omitted from the chain
> >
> > The client cannot decide that the signature on the root cert the server
> > sent is bad, if the server does not send the root cert.
>
> Yes, that
> On Oct 22, 2015, at 2:18 PM, Andrei Popov wrote:
>
> What if we just made an explicit exception for root cert hash algorithms and
> not constrained them by the client's alg list?
Yes, that would be substantially less bad. I still don't see any compelling
reason to shift chain validation po
On Thu, Oct 22, 2015 at 06:40:25PM +, Salz, Rich wrote:
> > Most applications want a simple API that hides all the complexities of
> > TLS. If OpenSSL had done that, then it would be easy to see how enabling
> > 1.2 won't cause problems for those apps which said "you take care of it".
>
> As
On Thu, Oct 29, 2015 at 03:07:58PM +0100, Hubert Kario wrote:
> On Wednesday 21 October 2015 20:17:31 Dave Garrett wrote:
> > Congrats on releasing an RFC that has day one 100% server support. :p
>
> oh, I'm sure there's at least one server out there that is intolerant to
> this one specific ext
On Thu, Oct 29, 2015 at 11:56:27AM -0400, Dave Garrett wrote:
> On Thursday, October 29, 2015 11:00:04 am Viktor Dukhovni wrote:
> > On Thu, Oct 29, 2015 at 03:07:58PM +0100, Hubert Kario wrote:
> > > On Wednesday 21 October 2015 20:17:31 Dave Garrett wrote:
> > > >
On Thu, Nov 05, 2015 at 06:47:51PM +0900, Martin Thomson wrote:
> Nitpicks accepted, pull requests preferred:
>
> https://github.com/tlswg/tls13-spec/pull/317
I am having a hard time figuring out what's changing. Can you
summarize the proposal?
I'd like it to say:
* The signature algorith
On Thu, Nov 05, 2015 at 04:59:18PM -0500, Dave Garrett wrote:
> On Thursday, November 05, 2015 04:38:34 pm Viktor Dukhovni wrote:
> > I'd like it to say:
> >
> > * The signature algorithms of self-signed certificates are
> > not subject to any constra
On Thu, Nov 05, 2015 at 06:53:46PM -0500, Dave Garrett wrote:
> On Thursday, November 05, 2015 05:05:02 pm Viktor Dukhovni wrote:
> > On Thu, Nov 05, 2015 at 04:59:18PM -0500, Dave Garrett wrote:
> >
> > > On Thursday, November 05, 2015 04:38:34 pm Viktor Dukhovni wrote
On Thu, Nov 05, 2015 at 08:15:31PM -0500, Russ Housley wrote:
> It might be useful to remind people about the difference between self-signed
> certificates and self-issued certificates. RFC 5280 says:
>
>Self-signed certificates are self-issued certificates where the digital
>signature m
On Sat, Nov 14, 2015 at 10:14:53AM -0800, Adam Langley wrote:
> 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),
Thanks, good news.
>// Signature curves.
>eddsa_ed2
On Tue, Nov 17, 2015 at 09:51:32AM -0800, Eric Rescorla wrote:
> My proposal is that we:
>
> - List all the Standards Track cipher suites that are compatible with TLS
> 1.3 in Appendix A.
>
> - Mark all the cipher suites that are listed in Appendix A as "Recommended"
Where does that leave cipher
On Tue, Nov 17, 2015 at 09:14:00PM +0200, Ilari Liusvaara wrote:
> > Where does that leave ciphersuites that are "Recommended" for TLS
> > 1.2, but TLS 1.3? Or do none of the CBC block ciphers in TLS 1.2 qualify?
>
> None of block ciphers (nor stream ciphers) work in TLS 1.3 at all.
>
> All cur
On Tue, Nov 17, 2015 at 09:26:57PM +, Short, Todd wrote:
> Embedded systems don�t have the luxury of mbuf-type of buffer scheme (as
> you describe for NSS). Many have ethernet-frame sized buffers in
> locked/pinned memory that read in a whole ethernet frame, and then strip
> off headers by adv
On Wed, Nov 18, 2015 at 11:07:59AM +0200, Yoav Nir wrote:
> Stateful firewalls tend to pass only what they understand. They use some
> measures to avoid tunneling and passing things that are not HTTPS over TCP
> port 443.
>
If the record layer header for application-data (not the initial
hands
On Thu, Nov 19, 2015 at 12:05:55PM +1000, Michael Gray wrote:
> > With several TLS implementations it is possible to completely seperate
> > network communication (of the application) from the processing of
> > TLS records (performed by the TLS protocol stack). For some TLS
> > implementations (e
On Wed, Nov 25, 2015 at 02:39:27PM -0500, Sean Turner wrote:
> After reviewing the list discussion, PR#317
> (https://github.com/tlswg/tls13-spec/pull/317) is okay to merge. Initially,
> there was some confusion about exactly what changes were being proposed
> (PR#317 is built on PR#231) but that
On Mon, Nov 30, 2015 at 10:34:27AM +, Peter Gutmann wrote:
> Bryan A Ford writes:
>
> >It would work just as well and in exactly the same way if the AEAD is
> >replaced with the traditional Encrypt-then-MAC construction, for example.
>
> No it wouldn't, unless the encrypt part is a stream c
On Tue, Dec 01, 2015 at 09:02:34PM -0800, Martin Thomson wrote:
> Ensuring that you know the length of the *next* record is difficult
> and could dramatically degrade latency, or adding extra bogus padding
> or extra bogus records. For instance, I can always send in bursts of
> two packets, a one
On Thu, Dec 03, 2015 at 03:49:02AM +, Jacob Appelbaum wrote:
> > It is far from clear that the privacy gains anything in the form of
> > practical protection. Having looked at it, I'm unconvinced. And I've been
> > a privacy/crypto advocate for a very very long time.
>
> I resolve DNS throu
1 - 100 of 592 matches
Mail list logo
