On Mon, Mar 21, 2016 at 6:05 PM, Eric Rescorla wrote:
> Folks,
>
> This revision is largely cleanup of a bunch of outstanding PRs and of
> issues found during interop testing. It should be largely wire
> compatible with draft-11 and also defines preliminary code points in a
> few places where we
Hey,
1. As I understand it, failure in these models is fairly catastrophic,
so I should be reading Table 1 as "chance of total collapse of
confidentiality",
not "chance of being able to read one plaintext" value. Is that
correct?
Actually, confidentiality will not collapse, the limit indicate
On Wed, Mar 23, 2016 at 12:38:13AM +, Timothy Jackson wrote:
> I’ve noted that many (most?) TLS implementations choose their ECDHE
> curves seemingly without regard to the cipher suite strength. Thus,
> they'll select an AES256 cipher suite (e.g.
> TLS_ECDHE_ECDSA_WITH_AES256_SHA384),
> but th
On Wednesday 23 March 2016 00:38:13 Timothy Jackson wrote:
> I’ve noted that many (most?) TLS implementations choose their ECDHE
> curves seemingly without regard to the cipher suite strength. Thus,
> they'll select an AES256 cipher suite (e.g.
> TLS_ECDHE_ECDSA_WITH_AES256_SHA384), but then genera
On Tuesday 22 March 2016 23:26:22 Dave Garrett wrote:
> X25519, secp256r1, X448, one of ffdhe3072 or ffdhe4096, and then
> lastly, ffdhe8192 and/or secp521r1 only as emergency backup
> (arguably, X448 belongs back here too)
>
> I'd like to specify ffdhe2048 (~103-bit strength) as "MUST NOT" use
>
* aluykx [23/03/2016 09:12:02] wrote:
> >Finally, and this calls for an opinion: do you believe that given these
> >results
> >we should include a KeyUpdate feature in TLS 1.3?
>
> Ideally it would be better to include a KeyUpdate feature, but the added
> complexity could risk introducing vulnera
I think that we're getting to the point now where a list might help.
https://github.com/tlswg/tls13-spec/wiki/Implementations
Add your implementation to the list, or talk to me about getting it added.
On 23 March 2016 at 18:43, Glen Knowles wrote:
> Is there a list of implementations somewhere?
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
Hiya,
I've done my AD review of this and have three questions
I'd like to ask before starting IETF last call. I mostly
care about the answer to #3. #1 is just a suggestion that
might avoid some process-crap and #2 is just me being
curious (unless #2 turns out to be a part of #3).
(1) Why experim
>>I’d state secp384r1 (...) as "NOT RECOMMENDED" to bother with,
>> but still permitted
>
>I'd say it is a tad bit too strong of a wording for the strongest curve
>supported by SChannel...
+1 to Hubert.
smime.p7s
Description: S/MIME cryptographic signature
___
"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
On 24 March 2016 at 11:38, Bodo Moeller wrote:
> The NPN dependency was a design decision for one implementation, but it's
> not common to clients using False Start. For interoperability, you always
> have to consider how to deal with what you expect to be deployed *currently*
> (and NPN support c
(This is probably already known to a bunch of people, but it's
probably a good idea to put out there.)
When deploying EMS, we recently discovered, with the help of our
friends at Google (who discovered this long before that) a quirk in
some implementations.
Short story: Don't place an empty exte
13 matches
Mail list logo
