Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources
draft-ietf-speechsc-reqts-07

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

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

[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 discuss] The suggested use of speech as a biometric authenticator over the Internet is in direct contradiction of the recommendations the cited U.S ...

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

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

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

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"