Re: [TLS] [Technical Errata Reported] RFC4492 (4783)

[Bodo Moeller]

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, and in that step, the client indeed
"conveys [...] information to the client in the ClientKeyExchange message":
that's certainly not something that implementors need to be told about, and
it's not what the authors of the specification meant to tell implementors,
but it's still correct. (It's also not strictly necessary to tell the
reader here that the ClientKeyExchange message will be sent to the server
-- it's not as if this element of the protocol would be underspecified if
we didn't have this information here.)

So, I certainly think that this really is a purely editorial error.

Bodo
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)

[Bodo Moeller]

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 save it anyway. However, given all the complexities of the TLS
handshake, there's actually more that can fall apart if the group is bad.)

Bodo
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Randomization of nonces

[Bodo Moeller]

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

Re: [TLS] AD review of draft-ietf-tls-falsestart-01

[Bodo Moeller]

"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 that esp if we really want people to move to
> TLS1.3. I also didn't see list discussion about what
> kind of RFC to aim for, but maybe it was discussed at
> a meeting or interim? (Apologies if I missed that in
> my scan of the list.)

I'm myself torn between "Experimental" and "Informational" (certainly not
"Historic" because the spec has not been superseded by a more recent one
and is not obsolete for any other reason [
https://tools.ietf.org/html/rfc2026#section-4.2.4], unless we somehow
manage to complete TLS 1.3 standardization before this). Taking into
account how False Start is actually deployed (and taking into account that
we expect it to eventually be replaced by a TLS 1.3 mechanism) and how our
I-D is cited in research papers on TLS, "Experimental" sounds right to me:
the spec really is part of a research and development effort [
https://tools.ietf.org/html/rfc2026#section-4.2.4]. "Informational"
wouldn't be wrong either.

> (2) The write up and some mail list traffic and AGL's
> bloggy thing all refer to NPN, but there's no mention of
> NPN or ALPN in the draft.  What's up with that? (Not
> saying that needs to be explained, but I wondered.)

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 certainly is one good indicator for False
Start tolerance, if you don't mind tons of false negatives), but I wouldn't
see much value in compiling the minutae of that in this kind of document:
it'll go stale quickly.

> (3) Why is there no description of the reasons for all
> the MUST only use whitelisted  and for the choices
> that are whitelisted?  Wouldn't omitting that tend to
> lead people to use this more badly?

Well, I tried to capture the general reasoning in the spec -- but not the
detailed reasons for the specific choices suggested, because that again
would just go stale quickly.

In particular, I think this is an important observation in the I-D:

"If heuristically a small list of cipher suites and a single protocol
version is found to be sufficient for the majority of TLS handshakes in
practice, it could make sense to forego False Start for any handshake that
does not match this expected pattern, even if there is no concrete reason
to assume a cryptographic weakness."

So the whitelists should have algorithms that are actually used in practice
and that don't have critical weaknesses, but why exactly those particular
algorithms happen to get used in practice is mostly out of scope here.

Bodo

> That could be done
> with some explanatory text and using some of the
> references below maybe. Or, if we don't really want new
> folks to implement this (do we?) then just saying that
> might mean it's ok to not explain the "why." (And then
> you could also address #1 above then by issuing this
> as an historic RFC too if you wanted.)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] List of implementations

[Bodo Moeller]

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 watch out for the extension during a
migration period, and if the extension is present, check that the value
provided agrees to the draft suffix of the version that eventually got
standardized. (More importantly, the draft implementations must be taken
out of use before anyone other than the early adopters completes their
implementation of the protocol :-) )

Bodo

*Version Negotiation*

Note that most of these implementations signal the draft version in a
two-octet extension that uses the code point 0xff02. Set this to the ASCII
encoding of the draft suffix (for example, draft -12 is the value 0x494a).
Until the final version is released, please require this extension before
negotiating TLS 1.3. If the value is not present, or it doesn't match your
implemented version you should negotiate TLS 1.2, or fail.
Am 23.03.2016 13:47 schrieb "Martin Thomson" :

> 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? I've started working on
> 1.3 as
> > a side project and just talking to myself may get lonely. :)
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] History of TLS analysis (was Re: TLS 1.2 Long-term Support Profile draft posted)

[Bodo Moeller]

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 problem of predictable IVs in the context of work
towards IPSEC, without making the connection to SSL.  Note that this was
before TLS 1.0 and, I think, before SSL 3.0.  SSL 2.0 already had
predictable CBC IVs but placed the MAC before the payload in the
to-be-encrypted data, which, through sheer luck, avoided the problem.

Bodo
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Editorial Errata Reported] RFC4492 (4633)

[Bodo Moeller]

"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.

Bodo
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Editorial Errata Reported] RFC4492 (4633)

[Bodo Moeller]

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.php?rfc=4492=4633
>
> --
> Type: Editorial
> Reported by: Kurt Roeckx 
>
> Section: 5.1.1
>
> Original Text
> -
> struct {
> NamedCurve elliptic_curve_list<1..2^16-1>
> } EllipticCurveList;
>
> Corrected Text
> --
> struct {
> NamedCurve elliptic_curve_list<2..2^16-1>
> } EllipticCurveList;
>
> Notes
> -
> The count is in bytes, not items.
>

I agree with this finding.  Each NamedCurve value takes exactly two bytes,
so the floor should have been specified as 2, not 1.

Bodo
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECDH_anon

[Bodo Moeller]

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 pattern started by DH_anon, I
prefer consistency with that one.

Bodo
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls