[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 []) 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-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 ([]) by localhost (core3.amsl.com []) (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 []) 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 []) 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 ([]) 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 ([]) 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 ([]) 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 ([]) by nok-am1mhub-04.mgdnok.nokia.com ([]) 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
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,


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


- 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:

  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

- Errata 1596 for RFC 4871. Waiting for the WG chairs to drive the
  discussion, and send the exact new text and recommended status to

  Relevant emails from 2008:

- The WG is currently (February-March 2010) discussing rechartering;
  Waiting for the chairs to send agreed text to IESG.


- The WG chairs have the token for doing something about ITU-T 
  X.1034 liaison statement.


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


- draft-ietf-isms-dtls-tm: currently in IETF Last Call; ends 2010-04-02.
  Nothing special to note.


- draft-ietf-keyprov-pskc and draft-ietf-keyprov-symmetrickeyformat: 
  current in Publication Requested, waiting for Tim to do his 
  AD review.


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

- (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

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


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


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

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



   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.


   I have sent Glen proposed text on 2010-03-11; waiting for his
   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.


   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]


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


   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.


   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.


   Waiting for the authors to submit a revised ID to address the
   comments from SecDir [since 2010-03-11].