Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources
RFC 4313

[Ballot discuss]
I'm picking up a discuss from Steve Bellovin:

sb>  The suggested use of speech as a biometric authenticator
sb>  over the Internet is in direct contradiction of the recommendations
sb>  the cited U.S. National Research Council study [14].  Note also the
sb>  comments that biometric authenticators must be treated as static
sb>  passwords when traversing a network -- they're subject to capture and
sb>  replay.  We do not permit use of plaintext passwords in IETF
sb>  standards.
sb>
sb>  I'm not (quite) prepared to insist that the material on biometrics be
sb>  deleted from the specification.  But I'd really like more discussion
sb>  of the concerns from the report in the Security Considerations
sb>  section -- a reader of just this document would have no hint that the
sb>  report says flat-out that this is a bad idea.  Beyond that, the
sb>  document must mandate use of confidentiality technologies for such
sb>  uses.

[Ballot discuss]
I'm picking up a discuss from Steve:

sb>The suggested use of speech as a biometric authenticator
sb>  over the Internet is in direct contradiction of the recommendations
sb>  the cited U.S. National Research Council study [14].  Note also the
sb>  comments that biometric authenticators must be treated as static
sb>  passwords when traversing a network -- they're subject to capture and
sb>  replay.  We do not permit use of plaintext passwords in IETF
sb>  standards.
sb>  I'm not (quite) prepared to insist that the material on biometrics be
sb>  deleted from the specification.  But I'd really like more discussion
sb>  of the concerns from the report in the Security Considerations
sb>  section -- a reader of just this document would have no hint that the
sb>  report says flat-out that this is a bad idea.  Beyond that, the
sb>  document must mandate use of confidentiality technologies for such
sb>  uses.


Going on with my own comments.  I'm frightened by the speaker
identification use case.  I believe this will be fairly hard to
support from a security standpoint and will probably slow down the
effort significantly.  This may well need its own security
requirements document if the WG chooses to go forward with speaker
identification in any sort of security situation.  If speaker
identification is not used for security but is maintained for other
reasons, then strong language explaining that none of the security
issues have been address is required.

If the WG does want to support biometric authentication they'll need
to demonstrate they have committed expertise in this area.

Here are some of the issues that you would need to consider.  Note
that I'm not familiar enough with biometrics to be convinced I've
enumerated all the issues.  Someone in the WG would need to
demonstrate they are familiar enough to go forward.

1) Biometric authentication requires trusted hardware.  Biometric data
is not private; I can get samples/recordings of fingerprints, voice
prints, etc.  Data can be replayed, etc.  You need to guarantee that
the hardwe is trusted by the verification server.  This means you need
to have security credentials on the hardware, to validate the path to
the server,  etc.  You also need to discuss policy, etc..

2) You need to discuss spoofing even with trusted hardware.

3) You need confidentiality for the data channels involved as Steve
points out.

4) You probably need to consider probabilities of collisions between
speakers

[Ballot comment]
Mmm... what was that RFC-Editor policy about acronyms in titles?
This doc has as title:
  Requirements for Distributed Control of ASR, SI/SV and TTS Resources
Quite a few acronyms, no?

[Ballot discuss]
The suggested use of speech as a biometric authenticator over the Internet is in direct contradiction of the recommendations the cited U.S. National Research Council study [14].  Note also the comments that biometric authenticators must be treated as static passwords when traversing a network -- they're subject to capture and replay.  We do not permit use of plaintext passwords in IETF standards.

I'm not (quite) prepared to insist that the material on biometrics be deleted from the specification.  But I'd really like more discussion of the concerns from the report in the Security Considerations section -- a reader of just this document would have no hint that the report says flat-out that this is a bad idea.  Beyond that, the document must mandate use of confidentiality technologies for such uses.

[Ballot comment]
I'm a no-ob on this because I don't think it will actively harm the effort
to get this work done, but there are a lot of requirements in here that
aren't well mapped to specific use cases.  The "VCR controls" noted in
4.5, for example make no sense for the speaker identification
use case given in 2.3, but those requirements are put forward as if
they applied to all use cases.

This document also trends away from the requirements to the design on
a number of cases (the xml:lang tag for multi-lingual TTS, for example).

The acknowlegemetns are, too say the least, interesting; the rules
indicating that it is a bad idea for a doc author and chair to be the
same aren't there to prevent appropriate acknowledgement when it
occurs--they're there to avoid conflicts in role.

[Ballot comment]
Section 3 of this document appears to be using RFC 2119 keywords, such as SHOULD, MUST, and MUST NOT, but RFC 2119 isn't cited as a normative reference.  The RFC should be cited, or text should be added to the document to describe what the upper-cased keywords mean in this context.

2002-12-09 - note from WG chairs to many folk

The Speech Services working group is completing a set of requirements for a
protocol to control speech services servers, such as Automatic Speech
Recognition and Text to Speech.

It is of considerable importance that the needs of speech/hearing impaired
and other handicapped users be accommodated in these requirements. We
believe that many needs are directly addressed in the requirements, such as
the ability to invoke TTS services so that speech impaired users may more
conveniently communicate with hearing users, or blind users have realtime
text read to them conveniently. However, it may be that we have missed some
important capabilities.

The IESG has encouraged us to have this document carefully reviewed before
we progress it to informational RFC and start using it to craft the
eventual protocol. Any feedback you have would be greatly appreciated. You
may send it directly to the speechsc working gourp mailing list -
speechsc@ietf.org. Please feel free to subscribe to the list if you find
the subject of general interest as well. Please also forward this on to
toehrs who may have interest in this work.

2002-11-27 - from allison
I'd like to see several specific changes to this draft:

0. The framework drawing is confusing.  Why is SPEECHSC on two lines?
  There needs to be more explanation of the protocol role in its
  two invocations.  Give an example as well of using SPEECHSC in a
  SIP application, since this document is the first appearance of
  SPEECHSC and is setting up its role in the community.

1. The requirement of the VCR-like control is not for all use - and it
  clearly treads on RTSP as described in 6.5 - the section needs a
  qualifier that it is for uses of SPEECHSC where there is streaming
  material that can be controlled, not for realtime-produced media.

2. Delete mention of msuri - it was not accepted as a SIP proposal on
  several tries

3. Reference RFC 3351 (SIPPING Deaf Requirements) and consider what
  are specific needs here - solicit review by
  Arnoud van Wijk, the editor of RFC of RFC 3351 and Rohan Mahy.
  This should actually be generalized to handicapped needs, which
  Rohan can give pointers for; an example is under VCR-like control,
  where there needs to be superfast TTS playout for a blind user.

4. SI/SV: Is there adequate support for the the apps to deal with
  their needs to handle false positive identifications, beyond the
  MUST for offline analysis, since network noise and error will
  undoubtedly complicate the situation, and we should understand
  what purposes these functions will be serving.  There should be
  very good timestamps and other features - privacy etc because
  of the abusability of SI/SV noise.

2002-11-27 - from bert
- Title uses unknown (at least to me) acronyms.
- Sect 2 talks about:
    OPEN ISSUES: This document highlights questions that are, as yet,
    undecided as "OPEN ISSUES".
  Id did not find any such opern issues anymore (which is good),
  So the note can be removed I think
- I see a number of places where a notation of: ?some text? is used
  Is that normal practice? And what does it mean?
  See sections 5.8, 6.2.3, 6.3... others
- I see normative references to "work in progress"