ietf
[Top] [All Lists]

Re: WG Review: CURves, Deprecating and a Little more Encryption (curdle)

2015-12-09 11:20:40
----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: "tom p." <daedulus(_at_)btconnect(_dot_)com>; "Harald Alvestrand"
<harald(_at_)alvestrand(_dot_)no>; <ietf(_at_)ietf(_dot_)org>
Sent: Wednesday, December 09, 2015 11:10 AM

On 09/12/15 10:43, tom p. wrote:

----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: "Harald Alvestrand" <harald(_at_)alvestrand(_dot_)no>; 
<ietf(_at_)ietf(_dot_)org>
Sent: Monday, December 07, 2015 11:30 AM

Hiya,

On 07/12/15 11:23, Harald Alvestrand wrote:
I think there's a piece of backstory here I'm not getting....

Den 04. des. 2015 18:05, skrev The IESG:
The protocols in scope are Secure Shell (SSH), DNSSEC, PKIX, CMS,
XML
Digital Signatures and potentially Kerberos and JSON.

Why is TLS not included?

It seems likely that the answer is one of:

1) TLS is already up-to-date in the space this group is limited to
2) TLS work is being done in the TLS working group

The latter, and a bit of the former:-)

There is also an active SSH list (albeit only about 5 message p.d.
lately which would barely be noticed on the TLS list:-(  and Simon
has
posted a message to the curdle list identifying some of that work;
and
you yourself have posted to it so you know about it!

Conversely, I do not see most of those active on the SSH yet taking
part
in curdle (nor do I see any mention of curdle on the SSH list).

Good point. I'll do that now.

Setting up this WG to look at SSH would seem divisive and unlikely
to
gain any meaningful momentum.

I don't get what you mean. AFAIK, there's no current proposal to
re-form an SSH working group. There is some chat on the list along
those lines but I didn't interpret that as indicating that folks
want to do a new WG. (If they did, I'd be happy to assist in
getting that done.)


I do think that the Security Area should be reaching out far more to
other areas to pro-actively provide guidance but do not think that
this
proposal has got it quite right.

Again, I'm not sure what you mean, can you clarify?

Stephen

RC4 would be a case in point.  The TLS WG decided it was unsafe and made
its feelings known with 'draft-ietf-tls-prohibiting-rc4'.  What it did
not do, AFAICT, was think through the consequences so we still have RFC
4642  with a MUST implement RC4.  It is known and will be fixed, but
would have been done so with less demands on the IETF had this
dependency been picked up earlier.  (I did check the RFC for the
applications I deal with, and
their form of words was not affected by this deprecation). But last
month,
I saw a WG Last Call of an I-D saying

SHOULD support  TLS_RSA_WITH_RC4_128_SHA

so it seems like the message has not reached the places it needs to.

Compression is another.  The TLS WG (my main source of information on
security matters) has removed it from TLS 1.3 because of a security
exposure but again, I saw it offered in an I-D and have seen no
general statement about whether or when it is considered safe or not.

Hashing is yet another.  As you have seen, the SSH list is debating the
use
of SHA-2 and referencing SHA-3.  The TLS WG has made SHA-1 SHOULD NOT.
Previously, the weakness of MD5 was IMO not well handled - it had a
weakness but it was a while before an I-D spelled out when it was and
when it was not safe.  SHA-1 needs something similar (unless you think
that RFC6194 does this:-(.

Truncated MAC is another good source of confusion.  Is SHA-384 better
than SHA-512 and if so, when? Could do with an I-D here.  And so on.

I have said before that security (like transport) is arcane and what I
mean is that I believe that WGs in other areas need help, in a way that
they do not in much of the rest of the subject material of an I-D, more
clear, current guidelines as to what is ok for the applications being
specified (which is likely a somewhat lesser level of security than NSA
would specify!).

Tom Petch

Ta,
S.

Tom Petch

In both cases, it would be nice to say so in the charter.

The charter text tries to do that generically but does mention
TLS specifically in this bit:

  "Where there is an IETF working group or area group with
expertise
in
   a relevant topic the CURDLE working group will defer to the
   consensus of the more specific working group as to where work
will
   be done. For example, the TLS, OpenPGP and IPSECME WGs are
actively
   considering some of these topics. "

Cheers,
S.