[secdir] Pasi's final AD notes (mid-March 2010)
<Pasi.Eronen@nokia.com> Thu, 25 March 2010 17:03 UTC
Return-Path: <Pasi.Eronen@nokia.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9E8F3A6CA5; Thu, 25 Mar 2010 10:03:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.24
X-Spam-Level:
X-Spam-Status: No, score=-3.24 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPa-V+gjy7v9; Thu, 25 Mar 2010 10:03:26 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id A18903A6B45; Thu, 25 Mar 2010 10:03:24 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o2PH3MSr029827; Thu, 25 Mar 2010 19:03:43 +0200
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Mar 2010 19:03:39 +0200
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Mar 2010 19:03:30 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Mar 2010 19:03:25 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 25 Mar 2010 18:03:24 +0100
From: Pasi.Eronen@nokia.com
To: saag@ietf.org, secdir@ietf.org
Date: Thu, 25 Mar 2010 18:03:33 +0100
Thread-Topic: Pasi's final AD notes (mid-March 2010)
Thread-Index: AcrMPRnbkVve3ufeQ2G8k87U2/6Jdw==
Message-ID: <808FD6E27AD4884E94820BC333B2DB775848688C66@NOK-EUMSG-01.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 25 Mar 2010 17:03:25.0088 (UTC) FILETIME=[15001A00:01CACC3D]
X-Nokia-AV: Clean
Subject: [secdir] Pasi's final AD notes (mid-March 2010)
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Mar 2010 17:03:28 -0000
I'm writing an expanded version of my notes so that Sean and Tim will have the information they need to continue the work. If you notice anything that doesn't look right, let Sean and Tim know -- miscommunication and mix-ups do happen. Best regards, Pasi MISC NOTES ========== - Planning AD transition with Tim/Sean - IETF 77 planning with Tim/Sean: SAAG meeting, SecDir lunch, overall agenda - (not wearing AD hat) draft-krawczyk-hkdf was approved by IESG; now in RFC editor queue. - (not wearing AD hat) Waiting for Dan Romascanu to process errata 1955/1956 for RFC 4072 [since 2009-12-09] - Lot of tools work to finish the datatracker UI changes. DKIM ==== - draft-ietf-dkim-deployment: was approved by IESG, now in RFC editor queue. If the WG decides to change its mind about errata 1532 (see below), appendix A.1.2.3 could require small changes. - Processed errata 1942. - Errata 1532 for RFC 4871: Currently (March 2010) being discussed. Waiting for the WG chairs to drive the discussion, and send the exact new text and recommended status to Sean. The conclusion back in 2008 is here: http://mipassoc.org/pipermail/ietf-dkim/2008q4/010820.html The dkim-deployment draft, appendix A.1.2.3 seems to be aligned the conclusion above. But given that we now have the dkim-deployment document ready (which has the recommendations for e.g. DomainKeys deployers), we probably want to edit the 2008 text slightly (at the very least, add a pointer to dkim-deployment) before marking it as "verified". - Errata 1596 for RFC 4871. Waiting for the WG chairs to drive the discussion, and send the exact new text and recommended status to Sean. Relevant emails from 2008: http://mipassoc.org/pipermail/ietf-dkim/2008q4/010820.html http://mipassoc.org/pipermail/ietf-dkim/2008q4/010818.html - The WG is currently (February-March 2010) discussing rechartering; Waiting for the chairs to send agreed text to IESG. EMU === - The WG chairs have the token for doing something about ITU-T X.1034 liaison statement. IPSECME ======= - draft-ietf-ipsecme-traffic-visibility: in RFC editor queue. Nothing special to note. - draft-ietf-ipsecme-esp-null-heuristics: was approved by IESG; now in RFC editor queue. Nothing special to note. - Processed errata 1919 (for RFC 4106) and 1937 (for RFC 4307). - draft-ietf-ipsecme-aes-ctr-ikev2: The draft was updated to address my AD review comments, but WG members found couple of additional minor nits that should be fixed before starting IETF last call. Waiting for authors to submit a revised ID [since early March 2010]. - draft-ietf-ipsecme-roadmap: I think we've roughly agreed on how to address my AD review comments; waiting for the authors to submit a revised ID [since March 2010]. ISMS ==== - draft-ietf-isms-dtls-tm: currently in IETF Last Call; ends 2010-04-02. Nothing special to note. KEYPROV ======= - draft-ietf-keyprov-pskc and draft-ietf-keyprov-symmetrickeyformat: current in Publication Requested, waiting for Tim to do his AD review. SASL ==== - draft-ietf-sasl-gs2 and draft-ietf-sasl-scram: in RFC editor queue, waiting for draft-altman-tls-channel-bindings. These went to AUTH48 already once; I approved the AUTH48 changes, but we changed draft-altman-tls-channel-bindings (see below) to be a normative reference, so they went from AUTH48 to MISSREF. The authors are currently discussing whether SCRAM needs some minor changes and/or clarifications related to error messages ("e=" parameter). - (not WG item) draft-altman-tls-channel-bindings: Back in October/early November 2009 there were discussions about how to make the text clearer about TLS session resumption and/or renegotiation. Although we mostly agreed on clearer text back then, the discussions were put on hold while the TLS renegotiation fix was done. However, the latest emails (March 2010) suggest that the text in -07 draft (and the 'tls-unique' IANA registration) isn't anywhere close to what Microsoft has actually implemented. The current plan is to update the draft (and IANA registration, when the draft is approved) to match what Microsoft implemented. However, this MUST be double-checked with Mark Novak, as the information about what the Microsoft code actually does has been somewhat inconsistent in the past. Alexey will be the responsible AD for this draft. - (not WG item) draft-melnikov-sasl-scram-ldap: in RFC editor queue/AUTH48 (waiting for GS2 and SCRAM). Thankfully, nothing special to note for this draft :-) - Errata 1812 for RFC 4013: I think the current text in the errata is OK, and it should be marked as "Verified" -- but I'm waiting for OK from Kurt (author of RFC 4013) before approving this [since 2010-03-12]. SYSLOG ====== - draft-ietf-syslog-sign: in RFC editor queue. Nothing special to note. - draft-ietf-syslog-dtls: still in WG, but probably coming to AD Evaluation soon. I'm expecting that all the security-related issues will be exactly the same as in RFC 5425 (Syslog over TLS/TCP), and UDP-related issues (like MTU, congestion, etc.) will be the same as in RFC 5426 (Syslog over UDP), and only very few DTLS-specific details will be new to this document. (And the new text about DCCP probably should be checked carefully.) Currently it looks like the document is copying some text from RFC 5425/5426, so it's not very clear what is new and what is the same. My guess is that it's easier to get this through IESG if we're referencing text instead of copying it... TLS === - draft-ietf-tls-extractor: published as RFC 5705. - draft-ietf-tls-rfc4366-bis: waiting for WG chairs/editor to drive discussion/propose text about the following topics: 1) The "server_name" extension contains a list of domain names. Apparently, existing clients only send one, and some servers ignore everything except the first one. Since it seems nobody is using multiple names (and there are some unclear aspects about their exact semantics), perhaps the spec should just forbid more than one name of same "name_type"? 2) The document probably should be clearer about how "server_name" and session resumption interact (or do not interact). In particular, are Session IDs scoped by "server_name"? (If they are, the client MUST send the same "server_name" when resuming a session.) If they are not, does the server ignore the "server_name" when it resumes the session (in case the "server_name" in the original session was different) or not? IMHO RFC 4366 is quite clear that "server_name" is completely ignored when the server resumes a session (so Session IDs are not scoped by "server_name", and the server does not check it against the original session), but perhaps it doesn't hurt to clarify this with some new text. 3) As noted in Stephen Farrell's SecDir review (http://www.ietf.org/mail-archive/web/secdir/current/msg01195.html), the document probably should explain why SHA-1 is OK and algorithm agility is not needed. Tim and I have agreed with the WG that this use of SHA-1 (without algorithm agility) is acceptable. "trusted_ca_keys" clearly does not need a cryptographic function, and client_certificate_url does not seem to be affected by collisions either (and this extension is rarely used, so creating a new extension with agility is not really useful work). 4) Joe thought the WG should also consider whether the renegotiation fix has any effect on the "server_name" extension. I don't think it necessarily does (beyond the one sentence that's already in RFC 5746). - (not WG item yet) draft-seggelmann-tls-dtls-heartbeat: waiting for the WG chairs to determine whether to take this as WG item. - (not WG item) see SASL WG for draft-altman-tls-channel-bindings - There is one errata (1077 for RFC 2818), but it's very unclear what, if anything, should be done about it. I've understood that the text in RFC 2818 isn't exactly what e.g. the major browsers do, but it seems this errata isn't either (and no, the major browsers don't all do the same thing either :-). Since there hasn't been any discussion about this errata, I'm just leaving it as "Reported"... DISCUSSES ========= draft-ietf-geopriv-lis-discovery Discussion currently ongoing. The authors have proposed simply noting that the security depends on DNS, but I would really like to see better arguments than "it's simpler to implement with some HTTP libraries" for ignoring this important security advice from RFC 3958. To me it looks like someone implementing HELD and this discovery mechanism can pick one of the many libraries that does support this, and this is not something that e.g. would have to work with all currently deployed web browsers. LoST had a quite reasonable description (RFC 5222, Section 18) why the approach recommended in RFC 3958 would not actually work in the deployment scenarios envisioned for LoST. But it seems the deployment considerations would HELD would be quite different, and the same argument does not apply here. draft-zorn-radius-pkmv1 I have sent Glen proposed text on 2010-03-11; waiting for his answer. I'm also hoping Glen reverts back to version -10 which used the RFC 2119 keywords (these were in the version sent to IESG, but got removed in -11), but that's not part of my DISCUSS. draft-ietf-bmwg-ipsec-meth/draft-ietf-bmwg-ipsec-term For ipsec-meth Section 12.x (where the proposed methodology measures setup latency, not setup rate), I think we've agreed to move those tests to an appendix (with a note saying they're not useful for comparing implementations, but might be still useful for internal SW/HW development). For other changes, I'm waiting for authors to submit revised IDs [since 2010-01-29] draft-cheshire-dnsext-nbp It has been 15 months since my DISCUSS, and I have been unable to get a single email reply from the author, despite pinging him and the responsible AD every couple of months. IMHO first asking the IESG to consider a document and then refusing to answer emails for this long is rude behavior. If the author doesn't have sufficient energy to engage in a discussion, he shouldn't have asked the IESG to consider this in this first place. I have asked Ralph to end this farce and declare the document dead several times, but he keeps saying the author has promised to work on this soon (but it's been "soon" for more then 8 months now). Since it seems the author has lost all interest, I'm not expecting this to really progress anywhere. The DISCUSS itself wouldn't be very difficult to address: the first and third concern are just one or two sentences. The second concern probably needs more thinking, but even then, I'm not expecting this document to come up with new solutions to known-to-be-difficult problems, just being realistic about a protocol might do (so text-wise, that could be something like two paragraphs). draft-ietf-tsvwg-port-randomization I think we have agreed on the changes (below); waiting for the authors to submit a revised ID [since 2010-03-04] Section 3.3.1: rephprase as "random() is a function that returns a 32-bit pseudo-random unsigned integer number. Note that the output needs to be unpredictable, and typical implementations of POSIX random() function do not necessarily meet this requirement. See [RFC4086] for randomness requirements for security." Section 3.4: recommend 128 bit keys instead of 32. draft-ietf-smime-cms-rsa-kem For the first issue (alignment with 18033-2/X9.44), I'm waiting for a reply from the authors [since 2010-03-11]. The second and third issues are minor, and I think we've agreed on the changes already. draft-ietf-csi-hash-threat Waiting for the authors to submit a revised ID to address the comments from SecDir [since 2010-03-11]. --end--
- [secdir] Pasi's final AD notes (mid-March 2010) Pasi.Eronen