On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL
wrote:
> What I am trying to avoid is the ability to *surreptitiously* subvert a
> protocol that’s assumed to be secure.
You don't seem to be hearing what I'm trying to say. What you are proposing
is physically impossible. It is a
It's fascinating that people cannot seem to stop picking at
the scab remaining after draft-green. I really think we'd be
wiser to just let the wound heal. (And get on with the work
that this WG has been chartered to do, which does not include
wiretapping.)
On 23/07/17 18:17, Felix Wyss wrote:
> H
On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:
> On 07/21/2017 09:34 AM, Hubert Kario wrote:
> > On Friday, 21 July 2017 15:38:32 CEST Benjamin Kaduk wrote:
> >> On 07/21/2017 08:23 AM, Hubert Kario wrote:
> >>> Signature Algorithms for ECDSA now define both the curve and the hash
> >>
On 07/24/2017 05:49 AM, Hubert Kario wrote:
> On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:
>> I'm afraid I don't understand this remark. There is the caveat to which
>> Ilari alludes, that the server can send whatever chain it has, if the
>> server can't send a chain that complies wi
Hi Nir, Josefsson & Pegourie,
As per section 5.2 server should send only "Supported Point Format" extensions
in server hello message. And it doesn't require to send "Supported Elliptic
Curve" extensions. Because of this if server is supporting only few Curves and
if it receives unsupported Elli
Ted Lemon writes:
> On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL
> wrote:
>> What I am trying to avoid is the ability to *surreptitiously* subvert a
>> protocol that’s assumed to be secure.
>
> You don't seem to be hearing what I'm trying to say. What you are
> proposing is ph
On Mon, Jul 24, 2017 at 10:03 AM, Brian Sniffen wrote:
> Ted Lemon writes:
>
> > On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
> >> What I am trying to avoid is the ability to *surreptitiously* subvert a
> protocol that’s assumed to be secure.
> >
> > Yo
It's fascinating that people cannot seem to stop picking at the scab remaining
after draft-green. I really think we'd be wiser to just let the wound heal.
(And get on with the work that this WG has been chartered to do, which does not
include
wiretapping.)
Sorry to ask for this so late in
Kyle Rose writes:
> On Mon, Jul 24, 2017 at 10:03 AM, Brian Sniffen wrote:
>
>> I could imagine making the server ECDH share dependent on the
>> client ECDH share, plus a local random value. At the end of the
>> session, the server discloses that random value, showing that it
>> properly constr
Of course, this is precisely the point. All your proposal does is complicate
the process of sharing sessions with a third-party: it doesn't stop an endpoint
from surreptitiously doing evil.
Is the objective to have the protocol prevent an endpoint “surreptitiously
doing evil”? Also, can y
On Mon, Jul 24, 2017 at 10:33 AM, Paul Turner wrote:
>
>
> Of course, this is precisely the point. All your proposal does is
> complicate the process of sharing sessions with a third-party: it doesn't
> stop an endpoint from surreptitiously doing evil.
>
>
>
> Is the objective to have the protoco
On Mon, Jul 24, 2017 at 01:48:13PM +, Raja ashok wrote:
> Hi Nir, Josefsson & Pegourie,
>
> As per section 5.2 server should send only "Supported Point Format"
> extensions in server hello message. And it doesn't require to send
> "Supported Elliptic Curve" extensions. Because of this if serve
> On Jul 24, 2017, at 16:27, Paul Turner wrote:
>
>
> It's fascinating that people cannot seem to stop picking at the scab
> remaining after draft-green. I really think we'd be wiser to just let the
> wound heal. (And get on with the work that this WG has been chartered to do,
> which does
Hiya,
I'm guessing many folks interested in TLS may have been
at the QUIC session in Prague and hence missed out on the
excellent talk by Stephen Checkoway on the juniper dual-ec
incident. (I highly recommend taking a peek at the slides [1]
or reading the paper [2] or watching the video wherever
On Mon, Jul 24, 2017 at 10:03:28AM -0400, Brian Sniffen wrote:
> Ted Lemon writes:
>
> > On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL
> > wrote:
> >> What I am trying to avoid is the ability to *surreptitiously* subvert a
> >> protocol that’s assumed to be secure.
> >
> > You do
On Jul 24, 2017 8:15 AM, "Stephen Farrell"
wrote:
Hiya,
I'm guessing many folks interested in TLS may have been
at the QUIC session in Prague and hence missed out on the
excellent talk by Stephen Checkoway on the juniper dual-ec
incident. (I highly recommend taking a peek at the slides [1]
or r
On Fri, Jul 21, 2017 at 02:37:42PM -0500, Benjamin Kaduk wrote:
> I'm afraid I don't understand this remark. There is the caveat to which
> Ilari alludes, that the server can send whatever chain it has, if the
> server can't send a chain that complies with the client's
> signature_algorithms.
"S
I believe what Raja is pointing out is that a server which accepts an ECDSA
*client* certificate has no way to advertise to the client which curves it
accepts. The signature algorithm list (and before TLS 1.2, the certificate
types) do advertise ECDSA as a whole, but not curves. E.g., a client with
Hmm, I'd appreciate a brief reminder* of why 1.3 needs nonces at all, given
that ephemeral DH is mandated, if anybody has the time/patience. (* ok, not
that I truly ever knew).
I assume that the risk of misusing the nonces, to exfiltrate keys etc, is small
enough compared to other side channels
On Mon, Jul 24, 2017 at 04:40:24PM +, Dan Brown wrote:
> Hmm, I'd appreciate a brief reminder* of why 1.3 needs nonces at all,
> given that ephemeral DH is mandated, if anybody has the time/
> patience. (* ok, not that I truly ever knew).
Two reasons:
- The DH shares can be reused (even if th
there was a discussion of adding a statement that a fresh ephemeral key MUST be
used for each session. It was decided not to do that. Without such a
requirement, nonces are needed.
Russ
> On Jul 24, 2017, at 12:40 PM, Dan Brown wrote:
>
> Hmm, I'd appreciate a brief reminder* of why 1.3 ne
On Mon, Jul 24, 2017 at 8:15 AM, Stephen Farrell
wrote:
> Now if some TLS1.3 deployment were affected by a dual-ec
> attack, it'd seem like the -21 version of Random might be
> even better than the TLS1.2 version, for the attacker.
>
I think the fix for this is really at the application level; i
On Mon, Jul 24, 2017 at 8:29 AM, Watson Ladd wrote:
> Don't use bad prngs. And don't buy products from vendors who ship back
> doors and refuse to come completely clean when confronted.
>
Just yesterday DJB posted a blog post about AES-CTR-DRBG, one of the most
widely-used PRNGs, and he points o
On Monday, 24 July 2017 15:09:48 CEST Benjamin Kaduk wrote:
> On 07/24/2017 05:49 AM, Hubert Kario wrote:
> > On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:
> >> I'm afraid I don't understand this remark. There is the caveat to which
> >> Ilari alludes, that the server can send whateve
For the most part, the presentation language (somewhat informally) described in
section 3 and its use throughout the document is clear, but the use doesn't
always match the description and some things are written in different ways. I
have a few examples below of the issues I've noticed. After th
On Mon, Jul 24, 2017 at 10:15 AM, Hubert Kario wrote:
> On Monday, 24 July 2017 15:09:48 CEST Benjamin Kaduk wrote:
> > On 07/24/2017 05:49 AM, Hubert Kario wrote:
> > > On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:
> > >> I'm afraid I don't understand this remark. There is the cave
> To clarify, you are arguing that P-384 should also be listed as MTI?
no, I'm arguing either for dropping the curve from signature algorithms, or to
bind RSA key sizes to hashes too
I don't think that either of these are good ideas.
+1
Both of these ideas are pretty bad, especia
Thanks for the quick answers.
Yet more naive quick questions: in the reused DH setting could a counter do
the job of random nonce? doesn't the record layer have an IV or nonce too? (or
is that passe?).
If these questions are too naive, or too last minute, let me know and I'll
withdraw them.
Colm MacCárthaigh writes:
>I think the fix for this is really at the application level; if you
>want defense-in-depth against PRNG problems, it's probably best to use
>separate RNG instances for public data (e.g. client_random,
>server_random, explicit_IV) and for secret data (keys) so that a
Hi David,
Thanks for your response.
If it is already fixed in TLS1.3, then I also feel ok to leave this behavior
for older version (TLS1.2 and earlier).
Recently I started reading TLS1.3 specification, I will go through fully to get
more info.
Regards,
Ashok
[
Hi Stephen,
Thank you for your nice work.
> Concretely, I think we should make the following changes.
> 1. Replace `length` with `TLSCiphertext.length` in the definition of
> `TLSCiphertext`.
I agree.
> 2. Replace `Hash.length` with `hash_length` throughout (9 instances).
I agree.
> 3. Chang
31 matches
Mail list logo
