If you keep using the same [EC]DH keys indefinitely, you're merely
pseudonymous, not anonymous :-)
Without a naming precedent, I'd still prefer [EC]DHE_anon over [EC]DH_anon
(and possibly "unauth" over "anon", because "anon" could be interpreted as
overpromising), but given the existing naming pat
RFC Errata System :
> The following errata report has been submitted for RFC4492,
> "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer
> Security (TLS)".
>
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search
"Glen Knowles" :
> To be pedantic wouldn't it be:
> NamedCurve elliptic_curve_list<2..2^16-2>
Arguably so, but that's not how the TLS RFCs use the presentation language
in practice (see ClientHello.cipher_suites for just one example), and we'd
want to be consistent with that, not extra nitpicky.
Watson Ladd :
The use of predictable IVs in TLS 1.0 was first commented on by
> Rogaway in 1995. (I'm hunting down the source, but this is from a
> presentation of Patterson)
I think you mean
http://web.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt,
which discussed the probl
Martin,
two remarks regarding the section "Version Negotiation" (quoted below).
1. The ASCII encoding of digit "1" is *decimal* 49, or 0x31 (the given
example 0x494a corresponds to "IJ").
2. It might be useful to remark that server implementations of the final
protocol version should still watc
"Stephen Farrell" :
> (1) Why experimental? Wouldn't this be better as info
> and documented as "here's a spec for a thing that's
> widely deployed." I fear we may get questions like
> "what's the experiment?", "where's this going in
> future?" if this aims for experimental, and info may
> avoid t
: Adam Langley
> Nagendra Modadugu
> Bodo Moeller
> Filename: draft-ietf-tls-falsestart-02.txt
> Pages : 10
> Date: 2016-05-11
>
> A diff from the previous version is available at:
> htt
Stephen Farrell :
> In support of Kathleen's comment and based on the shepherd's write-up,
> > why is this experimental and what is
> > the experiment?
>
> There's no good answer, sorry. I knew folks would ask, so I asked
> the WG and it seems to me to be a case that nobody cares really so
> the
That's https://eprint.iacr.org/2016/564 for those who'd like to see the
research (Mihir Bellare and Björn Tackmann).
Bodo
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Peter, so your complaint is about the lack of support for explicitly
specified (non-"named") groups? That's completely intentional, see the
RFC's abstract. (It *shouldn't* be that much of a problem that the server
might be using a ill-chosen group, because if the server does dumb things
we can't sa
Sean Turner :
> I think it ought to editorial because I don't think an implementer would
> have gotten it wrong;
>
It's also not strictly technically wrong. The client TLS implementation
hands the ClientKeyExchange message to the component of the client that
actually sends something to the server
> No, this is wrong. There is a client and there is a server, and
> whatever internal arrangements are made are epiphenominal from the
> perspective of this standard.
They certainly are, but that just means that, in that (unintended) reading
of the spec, it's using very contrived language to discu
12 matches
Mail list logo
